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 13:09, 2 April 2007 by Tiwebb.cisco.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

Jeff will write some notes here as an example. Jeff should feel free to draw on his experience with the current Update and with OSGi. Jeff will also suggest related pages to be read before the event. See also 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.

Back to the top