Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

GPW Lightning Retrospectives

Revision as of 18:45, 6 April 2007 by Dstevens.us.ibm.com (Talk | contribs) (Maya Incubator Project)

This page collects notes for Lightning Retrospectives prepared for the Ganymede Provisioning Workshop. You won't need to make slides to present at the workshop. We'll provide access to these pages and a big font. Use the following template and digress as you see fit.

(your project name here)

  • what code do you have
    • how good is it from a reusable framework perspective
  • what experience do you have
    • what can we learn from your experience that should influence our discussion at the workshop
  • what do we want
    • freely speculate about what you want from us or we should want from you in the Ganymede timeframe

See also: Lightning Retrospective Guide were similar notes were collected for the build workshop.


Equinox Provisioning Incubator

The evolution of Eclipse running in a wide range of runtime scenarios (e.g., tooling, RCP applications, cell phones and devices, and server) coupled with the increasingly dynamic nature of these computing environments is driving new requirements in the area of provisioning. Eclipse Update Manager has served well in relatively static, large-block, non-OSGi, tooling world but these additional requirements are exceeding the flexibility designed into Update Manager.

In response to this the Equinox team started an incubator to look at technologies and approaches to both meet the needs we see today and be flexible enough to meet needs we have yet to see.

The main goals of the incubator are to create an "extensible provisioning platform" that provides the base infrastructure and building blocks for provisioning systems that cover a wide range of usecases. Provisioning solutions lie along several intersecting axes.

  • fully client managed to fully server managed
  • coarse-grained "product" delivery to fine-grained "function" delivery
  • static component/version lineups to dynamically computed lineups
  • component-side component isolation to component pooling

The Equinox provisioning platform seeks to facilitate (though not necessarily directly provide) provisioning solutions at multiple points along each axis by separating the base provisioning mechanisms from the policies that drive those mechanisms.

The initial scope of this work is to create the base platform and enough concrete implementations to viably replace the current Eclipse Update Manager.

http://eclipse.org/equinox/incubator/provisioning http://wiki.eclipse.org/index.php/Requirements_for_a_new_update_manager

Maya Incubator Project

Maya is a new project to Eclipse being contributed from Cisco. While new to Eclipse, Maya is a technology developed within Cisco based on past provisioning experiences including working with technology used to manage thousands of Eclipse desktops. Maya is our ground-up rewrite to do managed provisioning the "right" way (disclaimer: Maya is our approximation of "right"; we look forward to further refining and evolving our understanding here at the workshop).

The Maya technology is being contributed to Eclipse as part of the new Maya project.

  • Maya is currently being used in a limited rollout within Cisco.
  • Maya was designed from day one with the intention of releasing to open source.
  • Maya architectural design is robust; certain individual components still maturing.
  • The technology is developed following Eclipse conventions for modularity and extensibility.

In approaching Maya, our experiences were based on past experiences using both Update as well as another internally developed provisioning platform used for a certain Eclipse-based tool stack.

  • End-user empowerment is key -- but not the base requirement. Many users of Eclipse tooling couldn't care about how the software gets provisioned, instead, they are interested in accessing the software they need.
  • Many users within an organization need to share a base stack of Eclipse tooling. In Maya we abstracted this notion into Profiles which can be shared by users. Users can then extend (add) additional software onto a Profile.
  • Discovery of software sources in an enterprise has been problematic; in Maya, we took the burden central for managing the list of update sites to be scanned and made available through Maya.
  • Users need to be able have access to multiple Eclipse Profiles ("stacks") at the same time.
  • Update technology when looking to address delivery of complex RCP tools needs to be significantly easier than what we would expect a developer to go through.
  • Provide a base framework that allows different vendors to offer value-add services to be deployed both server and client side (such as licensing, tool stack validation, etc.).

From a selfish point of view, we want to be able to pick up software from vendors and quickly deploy on our network without requiring changing out our provisioning or distribution infrastructure, or requiring users to manually install software on our system.

As a technology, Maya addresses some standard problems for Eclipse provisioning (in no particular order).

  • Single entry-point into multiple Eclipse profiles including software updates.
  • Automatic selection and failure/retry between download mirrors.
  • Ability to override mirror lists for Enterprise-internal download sites.
  • Plug-in and feature caching to be shared over multiple Eclipse instances.
  • Automation of dependency resolution when defining software for an Eclipse instance (Profile).
  • No need for end users to find or specify update site URLs as handled by administrator.

We are looking at the following for Ganymede:

  • An extensible model for provisioning in Eclipse whether single end-user deployments or centralized managed deployments.
  • A much simplified model for distribution better suited to do RCP applications in addition to the mode developer centric provisioning model of today.
  • A common paradigm for products to be defined and deployed without requiring customized installers or custom client-side technology for each system.

In addition to the notes above, we recommend reading over the following links and potentially browse the Maya newsgroup for some additional architecture discussions.

IBM Installation Manager

Back to the top