Difference between revisions of "Ganymede Provisioning Workshop Breakout Results"

Revision as of 16:45, 10 April 2007

Co-existence of multiple provisioners

• multiple sources
  • consistent UI / operations story
• multiple users
  • Linux experience but Vista issues, too
• interaction of multiple sources (priority, precedence, preference)
• validation of profiles
• licensing issues
• shared runtimes
• shared binaries
• repository discovery (RSS? Web servcies?)
• disconnected cases
  • media (including metadata and/or artifacts)
  • pending connection - future installation
• on-the-fly creation of native packages (in the background)
  • add dependencies on native bits (ex. adding a dependency on GTK for SWT so that if GTK is going to be removed, SWT will either also be removed or at least the potential for the removal will be presented)
• admin interaction
• touchpoints for native installation methods (ex. MSI, RPM)

Spectrum of Governance : Local control with central governance

• initial provisioning
• ongoing provisioning
  • points of control
    • "I am the governance provider" -- ensure that at the OSGi layer we can control who can activate bundles
  • potential for ongoing communication between provisioning server and client
    • license revocation or mandatory changes for other reasons
• hooks for governance both server and client side
  • validation at provisioning server
    • based on not only resolver but also other policies including software configuration settings
• spectrum of governance
  • fully managed
    • no or almost no client-side ui
    • user has no choice over what is installed and can not install additional software
  • partially managed
    • roles of user can differ (can they choose to install software)
    • governance may be required while end user is installing software
    • governance may be restricted to a certain set of "critical" components
    • potential for some user interface but may be restricted
  • no management
    • complete provisioning ui (comparable to existing update manager UI)

metadata for user

• end user and admins are users
• what is good for me to consume? Ready for prime time?
• Governance:
  • What does this person/role have
  • what is this person/roll allowed to consume? (permissions/access controls)
  • what can people change in the profiles
  • license management ( what licenses have been agreed to, which must be agreed to, license server locations, ...)
  • what profiles can I manage

• what does XX depend on?
• consistency checking (can I add XX)

• discovery
  • what do my friends have?
  • what function is available
  • search for things that fulfill a need
  • categorization of function
  • What is recommended. Ranking? interests? what did other people like like?
  • what repositories are available?

• has this lineup been tested?
  • are users happy/confident
  • known good / known bad
• what languages are available

• what are the system requirements?
  • can this run on platform X
  • cross platform validation/qualification
  • machine capabilities (cores, memory, cpu speed, connectivity, ....)
  • download size
• install branding
• Reporting
  • who (how many people) are using a particular lineup
  • what other configurations do I have
  • what other configurations are running
• how do I report bugs, related user forums
• settings and preferences
  • shared by role, organization, user, templates, ...
• install history
• can I roll back
• does this require a system restart or reboot
• what is needed so that I can run disconnected (whatever)
• what are the external constraints for this system (client/server version, ...)
• where do you enter the system?
  • product id? default perspective?
  • Enabled Capabilities, Welcome info?
• source used to build this IU
• extensible attributes of the metadata
• are there any post actions required (e.g., populate workspace, ...)

metadata for system

metadata for configuration