Revision as of 11:40, 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

Project intersections

Admin/Advanced UI

• Maya
• Equinox

Central Manager

• Maya
• Installation manager
• Expeditor
• Smartup

Tools

• Maya
• Equinox
• EPP
• Expeditor
• Installation Manager

Director

• Maya
• Equinox
• Smartup
• Buckminster

Engine

• Equinox
• Maya
• Smartup
• Buckminster

End-user UI

• Equinox
• Maya
• Installation Manager

Touch Points

• Equinox
• Maya

Native Installer/Boot strap

• EPP
• Maya

Repository

• Buckminster
• Equinox
• Maya
• Smartup
• Spaces

Transport

• Equinox
• Smartup

Delta Server/mechanism

• Smartup

Profile Management

• Equinox
• Maya
• Buckminster

Tools

• Equinox
• Maya

Core metadata

• Two aspects of metadata: system-level data, that needs to be processed for installing something and user-level data needs for showing meaningful information to the user (e.g. groups of install units, etc.)
• Core Metadata: the system side of metadata providing the information necessary for putting the system into a target state
• Metadata has to handle both system-level and user-level concerns.
• A grouping mechanism is needed, but cannot be mandatory for installing things. It should avoid duplicating dependency information.
• Metadata has to be extensible
• Allow to express cross-runtime dependencies and requirements (like needing a certain webserver, dll, compiler, etc.)
• Cross-runtime dependency: a dependency between two different kinds of runtimes. Example: a bundle in an eclipse-runtime needs a certain webserver
• Concepts:
  • "Installable Units" - something that gets installed, contains dependencies and has a descriptor of what the payload is
  • "Grouping" - groups a number of installable units. Groups are not mandatory.
  • "Constraint modification" - Allows to express limitations or expand limitations. Should allow to declaratively overwrite and change metadata to fix "screw-ups".

User workflows

• lots of different workflows for products
• we like the Firefox simple and low-key model
• Maya workflow:
  • user:
    • 1. start bootstrap
    • 2. pick profile from most popular
    • OR customize profile with list of available stuff
    • 3. launch profile
  • admin:
    • create / modify profiles
    • distribute profiles to others
• New user workflow:
  • • potential for many configuration screens (ex. location, licence, information collection, password)
    • progress dialogue during download/installation (same for media-based installation)
• Update workflow:
  • ideally there will be no need to "start over" with complete new zip
  • do away with infinitely growing footprint
  • look into keeping old / keeping (n - 1) versions
    • require API or per-product policy
    • being referred to as "garbage colletion policy"
  • compared with today, 'many' fewer choices presented to user
  • potential preferences:

    • [ ] Automatically download

      (on by default ideally)

    • [ ] Automatically install

      (not on by default)
• Areas of concern:
  • updating of non-user-writable bundles
    • interaction between Eclipse-based updater and system-wide updater
    • policy surrounding updating shared installs
    • support some sort of admin proxy (ex. PAM dialogue, admin password prompt)
  • profiles shared between machines
    • workspace, metadata (describing "profile"), user site (optional)
    • take some combination of above to a new machine and replicate system
      • perhaps some Import/Export mechanism