Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing Your Runtime With P2


Published on

Published in: Technology
  • Be the first to comment

Managing Your Runtime With P2

  1. 1. Managing your Runtime with p2 Pascal Rapicault IBM Rational TM , p2 lead
  2. 2. <ul><li>A provisioning solution for OSGi™ systems </li></ul><ul><ul><li>Managing non-running instance (only on Equinox for now) </li></ul></ul><ul><ul><li>Start level, framework extension </li></ul></ul><ul><ul><li>Bundle pooling </li></ul></ul><ul><li>An extensible provisioning platform </li></ul><ul><ul><li>Powerful dependency resolver based on SAT4J </li></ul></ul><ul><ul><li>“ Transactional” state change </li></ul></ul><ul><ul><li>Extensible set of actions </li></ul></ul>p2 is about installing!
  3. 3. Why should you care? <ul><li>Deploying and servicing is too often left as an afterthought, unfortunately it is your only connection with your user base. </li></ul><ul><li>p2 offers a foundation to your provisioning problems </li></ul><ul><ul><li>On a device </li></ul></ul><ul><ul><li>On a legacy Java server </li></ul></ul><ul><ul><li>On OSGi Server side application </li></ul></ul><ul><ul><li>On the cloud </li></ul></ul><ul><ul><li>… </li></ul></ul>
  4. 4. <ul><li>OSGi proves the power of componentization </li></ul><ul><li>Componentization naturally spreads </li></ul><ul><li>More components -> more management </li></ul><ul><li>Management is hard </li></ul><ul><li>It’s all about the Contract </li></ul><ul><ul><li>Defining </li></ul></ul><ul><ul><li>Instantiating </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Maintaining </li></ul></ul>OSGi is good for you!
  5. 5. How does p2 help for OSGi provisioning? <ul><li>Manages the contract </li></ul><ul><ul><li>Dependencies </li></ul></ul><ul><ul><li>Code </li></ul></ul><ul><ul><li>Settings (VM args, start level, etc) </li></ul></ul><ul><ul><li>Integrations </li></ul></ul><ul><ul><li>Non-OSGi parts (e.g. native launcher) </li></ul></ul><ul><li>Extensible </li></ul><ul><li>GUI and Headless </li></ul><ul><li>One consistent model from installation to servicing </li></ul>
  6. 6. <ul><li>From install to service </li></ul><ul><li>Concepts and Architecture </li></ul><ul><li>Configurability </li></ul><ul><li>Tooling </li></ul>
  7. 7. Unzipping is not installing
  8. 8. Initial deployment <ul><li>Installer </li></ul><ul><ul><li>p2 basic installer (~5/6M) </li></ul></ul><ul><ul><ul><li>Deployable using JavaWebStart </li></ul></ul></ul><ul><ul><li>EPP wizard [1,2] </li></ul></ul><ul><ul><ul><li>“ Shopping cart” approach to software selection. </li></ul></ul></ul><ul><ul><li>Home brewed p2-based installer </li></ul></ul><ul><li>Complete application (e.g. a zip file) </li></ul><ul><ul><li>The application results from a provisioning operation done at build time. [3] </li></ul></ul>[1] - EPP wizard - [2] - EPP Wizard talk - [3] – Director application doc -
  9. 9. EPP Wizard The user picks its software and a custom p2 installer is built.
  10. 10. Initial deployment <ul><li>Installer </li></ul><ul><ul><li>p2 basic installer (~5/6M) </li></ul></ul><ul><ul><ul><li>Deployable using JavaWebStart </li></ul></ul></ul><ul><ul><li>EPP wizard [1,2] </li></ul></ul><ul><ul><ul><li>“ Shopping cart” approach to software selection. </li></ul></ul></ul><ul><ul><li>Home brewed p2-based installer </li></ul></ul><ul><li>Complete application (e.g. a zip file) </li></ul><ul><ul><li>The application results from a provisioning operation done at build time. [3] </li></ul></ul>[1] – EPP wizard - [2] – EPP Wizard talk - [3] – Director application doc -
  11. 11. Updating, extending, … <ul><li>Two usage mode </li></ul><ul><ul><li>External mode , the p2 plug-ins are external to the application (e.g an installer) </li></ul></ul><ul><ul><li>Co-hosted mode , the p2 plug-ins are in your application (e.g. the Eclipse SDK). This mode still allows the application to be externally managed. </li></ul></ul><ul><li>User interface </li></ul><ul><ul><li>The p2.ui.* bundles, offering reusable dialogs </li></ul></ul><ul><ul><li>Agent running in the background checking for updates </li></ul></ul><ul><ul><li>Command line using the director application </li></ul></ul>
  12. 12. The controlled mode <ul><li>In comparison to the Eclipse SDK UI: </li></ul><ul><ul><li>Notice that the entry to choose a site is not available. </li></ul></ul><ul><ul><li>The preference page to add repo is also removed. </li></ul></ul>
  13. 13. Check for update on startup Details on UI customization available at:
  14. 14. Serviceability, the profile registry <ul><li>The profile registry reflects from a metadata standpoint </li></ul><ul><ul><li>What the user is currently running </li></ul></ul><ul><ul><li>What the user has been running </li></ul></ul><ul><ul><ul><li><install>/p2/org.eclipse.equinox.p2.engine/<….profile>/ </li></ul></ul></ul><ul><li>A profile can be used to recreate the user’s installation on another machine. </li></ul>
  15. 15. <ul><li>From install to service </li></ul><ul><li>Concepts and Architecture </li></ul><ul><li>Configurability </li></ul><ul><li>Tooling </li></ul>
  16. 16. One construct to rule them all Decouple decision making from the actual content Everything is an IU Everything is installable It is also referred to as “metadata” IU (id, ver)
  17. 17. Anatomy of an IU Provided Capabilities Required Capabilities Properties Artifact reference Actions IU (id, ver)
  18. 18. Anatomy of an IU, requirements / capabilities <ul><li>Capabilities and requirements are the mechanism by which an IU express what it provides and what needs. </li></ul><ul><li>A capability is composed of a: </li></ul><ul><ul><li>Namespace (string), name (string) and version </li></ul></ul><ul><li>A requirement is composed of a: </li></ul><ul><ul><li>Namespace, name and version range </li></ul></ul><ul><li>Namespace, name and version are open ended. </li></ul><ul><li>The requirements and capabilities expressed by IUs can be arbitrary and don’t have to all be in the same namespace. </li></ul><ul><ul><li>Resources – RPMs, .exes, docs, … </li></ul></ul><ul><ul><li>Virtual – if you can define a capability, I can depend on it </li></ul></ul>
  19. 19. Separation of concerns <ul><li>Installable Unit </li></ul><ul><ul><li>Exists independently of the repository </li></ul></ul><ul><li>Metadata Repository </li></ul><ul><ul><li>Store only Installable Units. </li></ul></ul><ul><ul><li>API, no specified serialization format </li></ul></ul><ul><li>Artifact Repository </li></ul><ul><ul><li>Store only Artifacts </li></ul></ul><ul><ul><li>API, no specified serialization or layout format </li></ul></ul>Metadata Artifacts
  20. 20. Artifacts <ul><li>Bytes/content to be installed </li></ul><ul><li>Any form </li></ul><ul><ul><li>JARs (e.g., bundles, features, …)‏ </li></ul></ul><ul><ul><li>Binary executables </li></ul></ul><ul><ul><li>RPM, MSI, … </li></ul></ul><ul><li>Multiple form </li></ul><ul><ul><li>JAR, pack200 </li></ul></ul><ul><ul><li>Binary diff </li></ul></ul><ul><li>Defined, maintained, loaded and used separately from the metadata </li></ul>
  21. 21. p2 Architecture Metadata Artifacts Runtimes Profiles OS Eclipse Engine Eclipse Classic Eclipse for C++ Other Planner Repositories Touchpoints
  22. 22. Terminology <ul><li>p2 / Agent </li></ul><ul><ul><li>The provisioning infrastructure on client machines </li></ul></ul><ul><li>Installable Unit (IU) </li></ul><ul><ul><li>Metadata that describes things that can be installed/configured </li></ul></ul><ul><li>Artifact </li></ul><ul><ul><li>The actual content being installed/configured(e.g., bundle JARs) </li></ul></ul><ul><li>Repository </li></ul><ul><ul><li>A store of metadata or artifacts </li></ul></ul><ul><li>Profile </li></ul><ul><ul><li>The target of install/management operations </li></ul></ul><ul><li>Planner </li></ul><ul><ul><li>The decision-making entity in the provisioning system </li></ul></ul><ul><li>Engine </li></ul><ul><ul><li>The mechanism for executing provisioning requests </li></ul></ul><ul><li>Touchpoint </li></ul><ul><ul><li>The part of the engine responsible for integrating the provisioning system to a particular runtime or management system </li></ul></ul>
  23. 23. p2 in Action Transports Http/Https File system Volume Planner Profiles Runtimes Provisioning operation requested Metadata fetched and constraints analyzed IU install, uninstall, update operations Artifact availability and mirroring Mirroring Data transfer IUs configured into runtimes Profile updated Repositories p2 Update Site Engine OSGi Native/OS
  24. 24. Touchpoint / actions <ul><li>The decoupling between p2 and the actual runtime being modified. </li></ul><ul><li>An action is a piece of code in charge of changing the system (e.g installing a bundle, setting a start level, etc.). An action can be context free or context bound. See ProvisioningAction </li></ul><ul><ul><li>Example of context free: chmod , unzip </li></ul></ul><ul><ul><li>Example of context bound: installBundle , setStartLevel ,… </li></ul></ul><ul><li>A touchpoint provides the context in which an action is executed </li></ul><ul><ul><li>For example the eclipse touchpoint provides its actions values such as the eclipse install folder, the bundle pool and is also used to cache some common data structure (e.g. the state of the fwk being modified) </li></ul></ul><ul><li>The extension point for touchpoint and actions is defined in the engine. </li></ul>
  25. 25. <ul><li>From install to service </li></ul><ul><li>Concepts and Architecture </li></ul><ul><li>Configurability </li></ul><ul><li>Tooling </li></ul>
  26. 26. Configurability <ul><li>p2 architecture allows for some of the key components to not all be in the same process. </li></ul><ul><li>Three known possible configurations, exemplified for OSGi </li></ul><ul><ul><li>Milli </li></ul></ul><ul><ul><li>Micro </li></ul></ul><ul><ul><li>Nano </li></ul></ul>
  27. 27. Internal management - milli Transports Http/Https File system Volume Planner Repositories p2 Update Site Engine OSGi Native/OS
  28. 28. External management - nano Managed application Agent Planner OSGi fwk The agent writes out file to control the application. The “provisioning” presence in the managed application is small. Engine OSGi Native/OS Repositories p2 Update Site Transports Http/Https File system Volume
  29. 29. External management - micro Planner OSGi fwk The decision making on what to install is done on the agent and communicated to the managed application (no remoting provided in the open source). The agent could also carry a copy of the profile registry. Demo - / Managed application Agent Engine OSGi Native/OS Repositories p2 Update Site Transports Http/Https File system Volume Repositories p2 Update Site
  30. 30. <ul><li>From install to service </li></ul><ul><li>Concepts and Architecture </li></ul><ul><li>Configurability </li></ul><ul><li>Tooling </li></ul>
  31. 31. Build, when the metadata comes to be <ul><li>Metadata matters </li></ul><ul><li>The p2.publisher is responsible for metadata / artifact generation </li></ul><ul><ul><li>Produces p2 metadata from bundles, Eclipse features and products </li></ul></ul><ul><ul><li>Can be used in any build system </li></ul></ul><ul><ul><ul><li>PDE Build is the richest (from source to repo) </li></ul></ul></ul><ul><ul><ul><li>Maven / tycho integration </li></ul></ul></ul><ul><li>Not all metadata can be inferred </li></ul><ul><ul><li>Actions to be executed on a given phase </li></ul></ul><ul><ul><li>Some tweaking is necessary </li></ul></ul><ul><ul><li>Author metadata advice </li></ul></ul>
  32. 32. Repository management <ul><li>Everybody creates repos, they need to be managed </li></ul><ul><li>Problems </li></ul><ul><ul><li>You want to promote one build over another one </li></ul></ul><ul><ul><ul><li>Composite repositories </li></ul></ul></ul><ul><ul><li>You build more than you want to make available </li></ul></ul><ul><ul><ul><li>Slicing </li></ul></ul></ul><ul><ul><li>You want to replicate builds from one repository to another </li></ul></ul><ul><ul><ul><li>Mirroring applications </li></ul></ul></ul><ul><li>Repository validation </li></ul><ul><ul><li>Repository validation that everything is installable </li></ul></ul><ul><ul><li>For every IU, each artifact is available </li></ul></ul><ul><ul><li>IU comparison tools, to ensure that the metadata is not changed </li></ul></ul><ul><ul><li>Artifact comparison tool to ensure that one artifact has not changed [1] </li></ul></ul><ul><ul><li>Repository diff’ing tool </li></ul></ul>[1] - Talk on versioning and provisioning -
  33. 33. <ul><li>From install to service </li></ul><ul><li>Concepts and Architecture </li></ul><ul><li>Configurability </li></ul><ul><li>Tooling </li></ul>
  34. 34. What is p2? <ul><li>A provisioning solution for OSGi™ systems </li></ul><ul><li>An extensible provisioning platform </li></ul><ul><li>A complete offering from Build time to Runtime </li></ul><ul><li>A community and an ecosystem </li></ul>
  35. 35. p2 in wild <ul><li>Installer for products (EPP Wizard, WindRiver, Motorola, IBM Rational, etc.) </li></ul><ul><li>Server managed deployment solution and distros (Genuitec, EclipseSource, Cloudsmith) </li></ul><ul><li>Remote management of device (EclipseSource) </li></ul><ul><li>Buckminster (Cloudsmith) </li></ul><ul><li>Cloud provisioning (EclipseSource) </li></ul><ul><li>Repository management (Sonatype) </li></ul>
  36. 36. References <ul><li>p2 landing page </li></ul><ul><li>All p2 articles </li></ul><ul><li>Getting the code </li></ul><ul><li>Contacting us </li></ul><ul><ul><li>Equinox newsgroup </li></ul></ul><ul><ul><li>Mailing list: </li></ul></ul>
  37. 37. <ul><li>Appendix </li></ul>
  38. 38. Profile <ul><li>A profile is the complete description in terms of IU of what is installed </li></ul><ul><li>A profile contains </li></ul><ul><ul><li>Properties defining the “environment” such as os, ws, arch, install location, bundle pool location </li></ul></ul><ul><ul><li>The list of IUs </li></ul></ul><ul><ul><li>Properties associated with IUs </li></ul></ul><ul><li>Class: Org.eclipse.equinox.internal.provisional.p2.engine.IProfile </li></ul>
  39. 39. Planning a profile change <ul><ul><li>Because of inter IU dependencies, </li></ul></ul><ul><ul><li>modification against a profile should be planned </li></ul></ul><ul><li>ProfileChangeRequest </li></ul><ul><ul><li>Capture the changes you want to make to the profile (e.g. Install, Uninstall). </li></ul></ul><ul><ul><li>The request is processed by the Planner </li></ul></ul><ul><ul><li>An update is a removal and an addition </li></ul></ul><ul><li>Planner </li></ul><ul><ul><li>The entity responsible for the evaluation of the change request, computing the transitive closure and checking the dependencies </li></ul></ul><ul><ul><li>If a solution exists it will find it </li></ul></ul><ul><li>ProvisioningPlan </li></ul><ul><ul><li>The planner returns a provisioning plan. The planning succeed pass or fail. Upon failure explanations are provided. Upon success the plan returns a set of operands to go from the initial state of the profile to the desired state. </li></ul></ul>
  40. 40. Engine <ul><ul><li>The mechanism by which the profile is actually changed </li></ul></ul><ul><li>The engine ensures consistency of the modification by performing a “transaction”. </li></ul><ul><li>Runs over a set of operands (usually resulting from a planning operation) and executes a given set of phases on them. No profile consistency validation is done </li></ul><ul><ul><li>Engine.perform(Operand[] ops, PhaseSet phases, IProgressMonitor pm) </li></ul></ul><ul><li>For each phase, the engine interprets from the touchpoint data of the IU, the action specific to the phase. The engine looks up the action to execute. </li></ul><ul><li>Currently 8 phases are defined, and the typical set of phases (and their order) is defined in DefaultPhaseSet . The design allows for new phases could be added. </li></ul><ul><li>The engine emit events on the IProvisoningEventBus to describe what is happening. Events on the bus are post events and can not be vetoed. </li></ul>
  41. 41. Installable Unit Fragments <ul><li>An installable unit fragment is an entity that attaches to an installable unit. </li></ul><ul><li>Much like OSGi fragments, IU fragments are used to complement an existing installable unit and appear as one with the IU they attached to. </li></ul><ul><li>They are typically used to deliver action to an installable unit (e.g. start level) because IUs should stay as context agnostic as possible </li></ul><ul><li>IU fragments can be attached to several IU at the same time. See for example the tooling.osgi.bundle.default IU that applies to all bundles. </li></ul><ul><li>Note that IU fragments are not how OSGi fragments are delivered. OSGi fragments are delivered as regular IU with requirements on their host. </li></ul>
  42. 42. Installable Unit Patches <ul><li>An installable unit patch has the ability to “modify” the requirements of any other installable unit. </li></ul><ul><li>Deal with three concerns: </li></ul><ul><ul><li>The IUs to which the patch apply </li></ul></ul><ul><ul><li>The lifecycle of patch </li></ul></ul><ul><ul><li>The changes applied </li></ul></ul>Note: In 3.5 the feature patch editor only exposes some of those capabilities .