Docstoc

Solution Deployment Descriptor Face to Face

Document Sample
Solution Deployment Descriptor Face to Face Powered By Docstoc
					 Solution Deployment
Descriptor Face to Face
     November 14-16
              Welcome
• Thanks to Macrovision and Rob Ross for
  Hosting this meeting
                             Agenda
• Monday 12noon-5PM PT
   – Introductions
   – Logistics – Rob Ross
   – Summarize where we are - Chair
   – Discuss Process to move forward - Chair
   – Discuss Software Lifecycle and how this applies to SDD – Randy
     George
   – Review Requirements Categories – Christine Draper
• Tuesday 9AM-5PM PT
   –   Present Brief Overview of related standards groups: Tom Studwell
   –   Review Detailed Requirements, Identify Obvious cases
   –   Accept In-scope requirements
   –   “Accept” Out-of-Scope requirements
   –   Discuss controversial requirements
                Logistics
•   Network
•   Dinner
•   Bathrooms
•   Etc…
                  Where we are…
• We have begun a specification document complete with Glossary ;-)

• We have collected 210 Use Cases, from 8 different
  companies/committees, which are potential candidates ways in
  which SDD may be used.

• We have collected lifecycle descriptions that define all the possible
  places where SDD may be relevant

• What we need to do…
    – We need to agree on a process to arrive at requirements
    – We need to agree on how the SDD would be used in the lifecycles
    – We need to resolve Requirements categories established in Use Cases
      and begin to determine which are in scope and out of scope
           Proposed Process
• Use Cases are useful but insufficient
• Lifecycles will help us
  – round out requirements and
  – establish in-scope/out-of-scope criteria
• Review Lifecycles and determine which aspects
  affect creation of vs use of SDD
• Review Requirements Categories to see if they
  match Use Cases and Lifecycle Usage
• Agree on what categories are in and out of
  scope for SDD
• Discuss and resolve the „uncertain‟ cases.
Notes, 11/14/2005
   Notes: Process Discussion
• Desired end result of face-to-face is a
  nearly-final set of in-scope requirements
  against which proposals can be made
• We‟ll take advantage of face-to-face
  exposure to debate the appropriateness of
  ambiguous use cases
         Notes: Lifecycle Discussion for
                 Scope Criteria
•   Randy‟s hypothesis: at some point in the life cycle, deployment meta-data is “frozen”
     –   Extra meta-data may be provided later on to add refinement or for other purposes
     –   A rule of thumb might be: if something is changed or provided after a CD is burned (or could
         be burned), it doesn‟t apply to SDD
     –   If a piece of info is mutable, probably doesn‟t belong in a static deployment descriptor
     –   Some examples from Randy:
           •   Licensing & entitlement – doesn‟t involve changes to the software “package” but is provided after the
               package is delivered
                  –   Debra: except for certain cases, for example GPL code which is immutable and viral.
                  –   Integrators should be able to know if 3rd party software is GPL-covered
           •   Readme file – if it‟s just FYI, not important
           •   The Features of a package – these are applicable, since they are critical info to deployers and
               integrators
           •   Localization & user-facing display information – some degree of this is applicable as it relates to
               deployment
•   Art‟s comment in question of this approach:
     –   All of this is really dependent upon our definition of the verbs used in this lifecycle: e.g.
         “Install”, “Configure”, “Deploy”

•   Suggested starting criteria for including information in our meta-data:
     –   Is it relevant to deploying, aggregating, or maintaining the software?
     –   Is it defined by the producer or integrator (and communicated to the deployer/maintainer)?
     –   Does it pertain to the nature of the software? In other words, could it sensibly be bundled
         with the software or is it provided at a different time or through a different channel?
•   We should factor in the degree to which this info applies to deployment
     –   Should we capture it in a first-class way or provide “hooks” or enabling info for it?
    Notes: Lifecycle Discussion for
        Scope Criteria (cont‟d)
• Keisuke asked to what degree bare metal installation is
  in scope
   – The group felt disk image deployment was generally in scope

• Debra pointed out the need to bake-in and automate
  specific deployment details, especially for internal
  enterprise deployment
   – Does the SDD become immutable once installation takes place,
     does it become modified to indicate what actually happened?
   – Can the SDD change once you install it?
   – The group felt that this should be possible, although there‟s
     some debate about the extent

• Art pointed out that our use cases define a system, of
  which the schema we‟re defining is a subset
   – For each use case we should identify the roles of the producer &
     consumer and identify how the schema needs to serve them
    Notes: Requirements Categories
•        Agreed-upon process:
    1.          Discuss the nature of the initial categories & agree they‟re in scope
    2.          Deep dive on ambiguous use cases to see if they‟re in scope
    3.          Deep dive on each category & make sure each of its requirements belong

•        All initial Categories found to be in-scope (at a high-level…individual requirements
         to be analyzed for scope in detail)

•        Clarifications made to Christine‟s requirement categories:
    –           “Solution Lifecycle Management” should include what‟s necessary to actually deploy and
                maintain software through its lifecycle
    –           “Requirements on Environment” pertains to requirements for all lifecycle changes, not just
                initial deployment
    –           “Changes to Envrionment” means the “promise” of what the package will do to the
                environment after each lifecycle change
    –           “Solution Variability” means the solution is like a Class whose variables are set for a
                particular Instance
    –           “Solution Composition” includes definition of content for one package as well as package
                aggregation
    –           “Solution Content” is confusing and should be revisited & recategorized
            •       For one, break out requirements for interoperability with other formats into a separate section
    –           Important to distinguish package localization from packages which deploy application
                localization
            Notes: Review of “External
                 Requirements”
•   99.1 [accessibility requirements]
     –   e.g. should always have a textual stand-in for graphical images
     –   Will be a general requirement: the SDD should not preclude Accessibility according to Section
         508 standards
     –   Will be added to a new “Compliance to Standards” section
•   99.2 [assistance in decision-making]
     –   We made sure some of these were captured in the “Variability” category
     –   Will create a new category “Decision Support” to capture the rest
•   99.3 [info for progress]
     –   Will discuss when James is present
•   99.6 [interactive selection and targeting]
     –   Some pieces need to be able to be referred to by a program through a key or ID
     –   To be added to the “Compliance to Standards” section
•   99.7 [environment changes to support changes]
     –   Already seems to be covered under “Requirements on Environment”
     –   99.7.1: not a requirement on SDD, but appropriate for another standards body
•   99.8 [build process]
     –   Authoring of an SDD must not require user interaction
               Notes: Review of “External
                Requirements” (cont‟d)
•   99.9 [development aggregation tooling]
     –   Tooling must be able to analyze requirements
•   99.10 [different management environments]
     –   We shouldn‟t prevent lower or higher levels of manageability
     –   This might be done by specifying different “levels” of SDD
     –   You could specify which minimum level you require
     –   For example, deployment of applications to cell phones might benefit from SDD packaging but the engine
         might utilize only a small subset of information
•   99.11 [aggregating readmes]
     –   Readmes and EULAs typically need to percolate up to the solution level when components are aggregated
     –   Keisuke pointed out that management tools could really use this information?
           •   Somehow mark certain files in the schema as a Readme or EULA
     –   This meets our criteria for consideration, but other issues arise:
           •   is there a reasonable standard way to capture this?
     –   The group agreed that this is good meta-data, but it it in scope of the SDD?
           •   We added requirements for this to the “Solution Description” section & will debate
     –   Is there a more general need for a way to mark files that might be viewed before installation with meta-tags?
     –   Incidentally, MSI supports declaration of readme, but not EULA
•   99.12 [externalized branding]
     –   This refers to the ability to package software in an OEMable format
     –   This is a use case, requirements: localization, aggregating content & overriding existing content
Notes, 11/15/2005
Notes: Related Standards Activities
•   Tom gave an overview of other applicable standards activity
•   CDDLM: Configuration Deployment Descriptor and Lifecycle Management (Global Grid Forum)
     –   Standardizing service to do the deployment
     –   We have approached them initially about referencing SDD, more will be done once SDD TC is further along
     –   Tatemura-san (NEC) is our liason to CDDLM
•   ACS: Describes a repository for applications
     –   Defines an interface to this repository
     –   Also defines an archive format for storing apps in the repository
     –   Fukui-san (Fujitsu) is our liason to ACS
•   Web Services Distributed Management (WSDM)
     –   Describes managed resources & manageability interfaces
     –   A natural mechanism for SDD packages to deploy their contents
•   Distributed Management Task Force (DMTF)
     –   Develops models for resources, artifacts, and hosting platforms
•   OSGI: OSGI bundles are somewhat similar to SDD packages
•   Datacenter Markup Language (DCML)
     –   Currently reorganizing and in transition
     –   We don‟t currently have a liason
•   James asked at what point other groups can view our requirements & comment?
     –   Tom: it‟s up to this committee to determine the timing
•   Also, when are we planning to look at their input & review their content?
     –   That‟s the responsibility of the liason for each group
         Notes: External Requirements
                    (cont‟d)
•   99.3 [progress messages]
     –    This is mostly covered by our use cases
     –    We‟ll note that implementations are free to run operations in parallel unless otherwise specified by dependencies
•   99.4 [error logs]
     –    Identity information used in logs is captured in requirement 6.2
     –    Debra: could the deployment descriptor indicate possible failure conditions when installing that would be referenced in the logs?
             •   Could also define a message for the user what the next step should be
                     –   By including this in the SDD descriptor, could be re-presented in an aggregated package
                     –   If this is left to the tooling, it may get lost
             •   Should look at use cases and scenarios
             •   We‟ll classify as additional meta-data that could be provdied with the SDD package.
•   99.5 [admin privileges shouldn‟t have to be required]
     –    Will be added to requirement 2.1.3
     –    James warns that if SDD gets down to specifying specific usernames & groups for installing files, it also needs to handle the non-
          root case
     –    Do we need a way to specify requirements on the existence of users & groups?
     –    James wants package authors to be able to declare that their artifacts & files should be installed with a particular ownership
     –    Does this belong in the SDD description or the deployed artifacts themselves?
     –    We‟ll add a requirement to the “Requirements on Environment” category
     –    We should note that package authors should define the least amount of privilege required to install an application
•   99.13 [licensing and registration]
•   99.14 [silent/unattended install]
     –    Covered by our requirements – Use Case 112 will be mapped to these
•   99.15 [remote install]
     –    We have physical packaging requirements to support efficient use of data – we mapped this use case to these requirements.
•   99.16 [interoperability with management systems]
     –    The group feels this is best handled by collaboration with other standardization efforts
     –    This may also relate to the idea of Levels of Compliance – if one runtime supports level X, other runtimes that support level X should
          be compatible
    Notes: External Requirements
               (cont‟d)
• 99.17 [update and uninstall of shared components]
   – Good requirements but don‟t drive any new requirements for the
     schema. Will be mapped to some requirements in Category 3
• 99.18 [snapshotting of a solution]
   – Ability to find out all the decisions made during an install and
     capture them for duplicated installs
       • Even including what‟s changed since the install
   – Debra suggests that we keep the round-trip path in mind when
     defining a schema
• 99.19 [user override of errors]
   – Allow the caller to make decisions or changes that would prevent
     a reversion upon failure
• 99.20 [out of band changes]
   – A requirement for the engine/tooling, not the schema
         Notes: External Requirements
                    (cont‟d)
•   99.21 [grid requirements]
     –   149: All application components should be able to be bundled into one archive – this was already captured as a requirement, use
         case has been mapped.
            •   Also refers to package integrity – a requirement was added to capture this.
     –   150: Should support a diversity of content types to be installed
            •   We hadn‟t had this as an explicit requirement but added one.
     –   151: Should allow deployment to geographically separated environments
            •   This is already captured for distributed environments
     –   152: All info for grid task is stored within the archive
            •   Our requirement is that we won‟t preclude any extra meta-data or content in a package.
     –   153: SDD Extensions for ACS namespace elements
            •   Keisuke‟s suggestion: have xsd:ANY regions in the SDD to capture custom extended info
            •   How does WSDM provide custom extensions to its schema?
            •   ACS open for public review & comments in December ‟05
     –   154 & 155: Operation granularity & incremental updates
            •   SDD archives should reflect the bundled files as naturally as possible & conform to archive standards, so as not to preclude ACS-
                compliant repositories from updating them incrementally
     –   156: Archive file format
            •   SDD Charter calls for a standardized package layout, including when packaged as an archive
            •   We also added a reuirement to specify minimum set of archive file formats
     –   158: Differential archives
            •   It should be possible to send only the necessary material over the wire to optimize network usage
     –   159: Redundancy elimination
            •   Combining external file references & internal reducdancy elimination, this is covered
     –   160: Access control
            •   Enabled by our package identity requirements
            •   In addition, we shouldn‟t preclude packages from being encrypted, even when aggregated
            •   In ACS, describes access constraint in ACML standard (only meaningful if the system enforces it)
            •   SDD doesn‟t have anything to say about system-provided security enforcement
     –   161: Opacity of contents
            •   Met by currently defined requirements
         Notes: External Requirements
                    (cont‟d)
•   99.22 [other maintenance requirements]
     –   These items were pointing out how the basics of requirement & validity checking applied to
         maintenance operations, not just the initial install
     –   We added a single requirement stating this fact
•   99.23 [debug]
     –   If we provide declarative error codes, we may allow them to be marked as Debug rather than
         Production, for developer testing
•   99.24 [localizing SDD descriptions]
     –   We hadn‟t had an explicit requirement for this, but added one
•   99.13 [licensing]
     –   Auditing compliance with the license agreement
           •   Requires the application identity already required for SDD
     –   “Activation”
           •   Generic variability mechanisms enable package to let users pass in data”
           •   Does it make sense to call this out as a specific element?
                  –   Should examine practical scenarios to see if this really makes sense
     –   Registration
           •   Generic variability accounts for this
           •   May be ancillary given the goal of SDD to focus on deploying solutions into a datacenter
           •   Will research other efforts in the industry (e.g. OpenGroup Systems Management License Use
               standard)
Notes, 11/16/2005
         Notes: External Requirements
                    (cont‟d)
•   99.13 [licensing, cont‟d]
     –   Auditing and metering
           •   Another use case mapped to application identity
     –   Return receipt
           •   We won‟t preclude this
     –   Single-user license key
           •   We won‟t preclude this
     –   EULA Acceptance
           •   Should SDD packages be able to declare their EULA?
           •   Also, should they be able to reference these in component packages when aggregating solutions?
           •   To what extent are EULA-agreements context-specific & relate to installer front-end vs. application package?
     –   License events
           •   We‟ve forgotten what this meant – will wait for Jay Nash
•   Use case 123 [component model]
     –   This is covered by our other composition use cases
     –   However, we‟ve added a requirement to state best practices for composition
•   Use case 127 [layout of components]
     –   Aggregated solutions need to be able to override the relative locations of where things are installed
     –   This is captured by our requirement 5.2 which provides for the overriding of parameters
•   Use case 138 [system privileges]
     –   Maps to our earlier defined use case for user privileges
     Notes: External Requirements
                (cont‟d)
• Use case 144 [encryption of sensitive data]
    – We added a requirement for this
• Use case 147 [multiple installations]
    – We refined some requirements in “Requirements on Environment”,
      “Projected Changes”, and “Best Practices”
• Dell use cases
    – These were mainly covered by existing requirements – we mapped them
      as appropriate.
    – We clarified that the role of SDD is to declare manageable packages, but
      actual code for provisioning systems or front-end installer applications
      would be outside the scope of this workgroup (even if packaged in the
      same physical archive)
    – We noted that a combination of SDD & other standards (e.g. WSDM)
      can provide a good framework for the standardization of hardware &
      firmware updates
    – We got to use case 203, still need to cover 204-210
                      Tactical Action Items
•   Make changes to requirements doc as indicated by the Comments [Tom, 11/17/2005]
•   Flesh out the content of the requirements document [various, 11/23/2005]
•   Confirm all use cases in spreadsheet are captured somewhere in the Categories document [Debra, 11/23/2005]
•   Cross-reference use cases in spreadsheet to requirements [Debra, 11/23/2005]
•   Update the glossary [Randy, 11/18/2005]
     –   Provide distinguishing definitions for “integration” and “composition” terms
     –   Describe what a “package” is
     –   Identify all overloaded, ambiguous, or missing terms
     –   Distinguish between “End User License Agreement” and “Licensing & Registration” (license keys, etc.)
•   Requirement analysis tasks:
     –   Submit and analyze requirements for “generic add-ons”. We currently have requirements for language packs in particular, but we
         realized today that this may be an instance of a more general case for add-ons (e.g. Eclipse plugins, ISMP platform packs, etc.)
         [Josh, 11/23/2005]
     –   (done) Submit and analyze requirements for including in a descriptor the version of the standard used to create the descriptor
     –   (done) Discuss Sun‟s “External Requirements” when James Falkner is present:
            •   99.3, 99.4, 99.5
     –   Revisit revert-upon-failure requirements to cover: [Debra, 11/23/2005]
            •   When a minor piece fails to deploy, don‟t force a revert
            •   Are there pieces which, once deployed, shouldn‟t be reverted, even if the overall solution fails to deploy?
     –   Refine Requirements 2.1 & 1.1.3 to make the following clear: [Tom, Debra, 11/23/2005]
            •   Non-dependent operations may run in parallel
            •   Allow requirements to be defined either as having to be satisfied before the installation or by the end of the installation.
     –   Ensure that Use Case 112 (silent installs) is mapped to all appropriate requirements [all, 11/23/2005]
•   Zulah (BEA) to approach DCML to become the liason between that group and SDD [Zulah, 11/22/2005]
•   Tom: find a liason into the SMASH committee [Tom, 11/30/2005]
•   (done) Tom: attempt to contact Jay for possibly attendance at the meeting
•   Create a working schedule for the TC to reach completion milestones of charter deliverables [Tom, 11/30/2005]:
     –   Set of specifications including SDD schema (Charter target: January 2006)
     –   Package format specification (Charter target: January 2006)
     –   Primer & examples (Charter target: April 2006)
     –   Requirements forwarded to other standards bodies (Charter target: April 2006)
     –   Best-practices (Charter target: April 2006)
                         Parking Lot Topics
•   Define the levels of compliance to the SDD to which exploiters can provide implementations
     –   Possibly in a separate document, possibly include in the primer
     –   Determine extent to which this can be defined by this group
•   Plan when & how to approach other workgroups to review & solicit input
•   Compare other general-purpose package formats with the SDD
     –   What information does the SDD not capture, and is there a good reason for this?
•   Review the ACS specification, available in December ‟05
     –   Identify logical extensions that ACS needs from SDD
     –   Identify technical approach to providing extension points
           •   xsd:ANY?
           •   Separate descriptor with references?
           •   Explicitly-typed additions to the SDD?
•   Deep-dive on practical scenarios for declaring failure conditions & recovery steps in SDD
     –   Analyze whether “debug-time” failures should be distinguished from those that occur in production
•   MVSN action item: review the OpenGroup Licensing effort to determine applicability to SDD
•   Define an architecture of the SDD package, answering the following questions:
     –   What parts of an SDD Package are “first-class” SDD elements?
     –   In what way are ancillary resources stored & located in an SDD package?
     –   Does the “SDD package” logically consist of just the meta-data and related resources, or does it include the
         Installer UI & other “front-end” resources?
•   Are there widely-applicable and important use cases that would be served by consistently
    declaring End User License Agreements (EULAs) in an SDD?

				
DOCUMENT INFO