1 / 14

Deliverable

Deliverable. A meeting report that outlines our current thinking about Private PlanetLabs and Federation. Private PlanetLabs: Opportunities and Challenges Todo Pound out an outline (this afternoon) Distribute paragraph generation (tonight & tomorrow). Framework Questions. What is PlanetLab?

wind
Download Presentation

Deliverable

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deliverable • A meeting report that outlines our current thinking about Private PlanetLabs and Federation. Private PlanetLabs: Opportunities and Challenges • Todo • Pound out an outline (this afternoon) • Distribute paragraph generation (tonight & tomorrow)

  2. Framework Questions • What is PlanetLab? • Operational system, software package (platform), arch, community model • What role PLC? • Ops, core development, specs, integration • Community • Innovating on top of PL • Contributing to PL itself • enablers: stable interfaces, myPLC, documentation) • Goals • Scale (parallelize/amplify PLC) • Enable community

  3. Private PlanetLab Enable customization Localization Funding Policies Isolation Safe testing Solve local problems Distr. Virtualization Deploy services for local users Federate Scale ops Private regional + fed Need more resources (cycles + net effect) Join community (peers) Buy from providers Access to services Users, not just developers Altruism Why?

  4. Risks • Divergent platform (harder to code to) • Divergent policies (prohibits certain slices) • Fragmented from user’s perspective (harder to secure needed resources)

  5. Strategy to Mitigate Risks • Keeping common architecture makes federation is technically feasible • Keeping common code base lessens code diversity risk • Keeping common ops base lessens fragmentation risk (inter-NOC) • Keeping common policy lessens fragmentation risk (shared AUP) • Keep incentives in mind (market-based)

  6. Software Development Issues • Types • Bug fixes • Generalizations (enable new capabilities) • Specializations/Enhancements (new capabilities) • Model • Patches / developer access (BSD model) • Limited by build/QA process • Borrows from Linux model • “Linus” decides (colored by operational requirements) • Intermediate testers/integrators (private planetlabs) • Well-known long-term architectural vision • Borrows from Amazon: Continuous release (node groups) • Sync’ing (upgrading) private PlanetLabs

  7. Operational Support Issues • Training • Mgmt people (Best Practices) • User Education (and help desk) • Inter-NOC coordination • 3rd Party Management Services • Stork, CoBlitz, CoMon… • Sync’ing with PLC w/out disruption

  8. Technical Challenges • PlanetLab/Cluster integration • Slice gets VM from the cluster • Slice gets a substantial chunk of the cluster • Slice a wireless access point • Slice a “gateway” to the Internet (e.g., BGP) • Feed “live” PL measurements into Emulab • Performance • Hardware-assist • Kernel mods

  9. Technical Challenges (cont) • Scheduling to support low-jitter services • Generalize RSpec/NM • Alternative VM types (e.g., Xen) • Richer node types (e.g., ns -> XML) • Service composition • Dependencies across federated PLs

  10. Friday’s Agenda • Source code base (Mark) • Clusters (Marc) • Lists • 6-12 month todo list (PLC and elsewhere) • Ops • Code • Arch/Documents • Wish list (longer term)

  11. Extra Slides Follow

  12. Discussion Points • Motivation/Rationale • Process-related issues • Software Development • Operational Support • Federation • Technical Challenges

  13. More details on “Why” slide • Grow public PlanetLab • Scale operations beyond a single PLC • Make more aggregate resources available • Internationalization • Accommodate different policies • Can get funding from local sources • Manage distributed machines • Common point-of-pain w/ minimal “public PL” impact • Pair-wise peering will naturally follow • new communities spring up • Specializing/Extending • Researchers want a playground • Deploying useful services in new environs

  14. Federation Issues • Refine the architecture/interfaces • Peering agreements • Right resource control/allocation knobs • AUP • Transitioning to independent MAs/SAs • Common (seamless) user experience • Internationalization • Membership agreement • Differing AUPs

More Related