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

Difference between revisions of "Ganymede Provisioning Workshop Breakout Results"

(Co-existence of multiple provisioners)
Line 1: Line 1:
 +
= Day One Results =
 
== Co-existence of multiple provisioners ==
 
== Co-existence of multiple provisioners ==
 
* multiple sources
 
* multiple sources
Line 159: Line 160:
 
Does xyzzy support emacs shortcuts?
 
Does xyzzy support emacs shortcuts?
  
== metadata for configuration ==
+
= Day Two Results =

Revision as of 10:03, 11 April 2007

Day One Results

Co-existence of multiple provisioners

  • multiple sources
    • consistent UI / operations story
  • multiple users
    • Linux experience but Vista issues, too
  • metadata compatibility - common basic metadata (install registry) plus source specific properties/extensions
    • how to avoid duplicate information/properties?
  • 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?
    • something like Mugshot Application usage http://mugshot.org/applications ?
  • has this lineup been tested?
    • are users happy/confident
    • known good / known bad
  • what NL 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

Resource/runtime/service requirements Platform information

state of installable units What is installed?

Qualification What touch points do you need

Exclusivity Singleton

transports available Internet connection? Speed? Local connection vs end to end What transports available to get this artifact? What repositories contain this metadata/artifact?

What metadata is new since xyzzy?

Who provides beer when the developers make a mistake

What are install operations that will be done?

What installable units will be installed/replaced/uninstalled?

Repository questions - binary deltas, latency, fastest mirrors

Security - is there a proxy


Authorization level Restart required

Will configuration be valid

time/size(download, memory) to perform

licensing consequences

system locale languages to install

languages supported what are your dependencies power consumption

system view/all users view/private view

vendor signed hashes/md5 downloaded correctly

alignment


Suggests/recommends

Does xyzzy support emacs shortcuts?

Day Two Results

Back to the top