Solution Deployment Descriptor Face to Face

1
Solution Deployment Descriptor Face to Face

• November 14-16

2
Welcome

• Thanks to Macrovision and Rob Ross for Hosting
  this meeting

3
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

4
Logistics

• Network
• Dinner
• Bathrooms
• Etc

5
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

6
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.

7
Notes, 11/14/2005
8
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
• Well take advantage of face-to-face exposure to
  debate the appropriateness of ambiguous use cases

9
Notes Lifecycle Discussion for Scope Criteria

• Randys 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 doesnt apply to SDD
• If a piece of info is mutable, probably doesnt
  belong in a static deployment descriptor
• Some examples from Randy
• Licensing entitlement doesnt 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 its 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
• Arts 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

10
Notes Lifecycle Discussion for Scope Criteria
(contd)

• 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 theres some debate about the extent
• Art pointed out that our use cases define a
  system, of which the schema were 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

11
Notes Requirements Categories

• Agreed-upon process
• Discuss the nature of the initial categories
  agree theyre in scope
• Deep dive on ambiguous use cases to see if
  theyre in scope
• Deep dive on each category make sure each of
  its requirements belong
• All initial Categories found to be in-scope (at a
  high-levelindividual requirements to be analyzed
  for scope in detail)
• Clarifications made to Christines requirement
  categories
• Solution Lifecycle Management should include
  whats 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

12
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

13
Notes Review of External Requirements (contd)

• 99.9 development aggregation tooling
• Tooling must be able to analyze requirements
• 99.10 different management environments
• We shouldnt 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

14
Notes, 11/15/2005
15
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 dont currently have a liason
• James asked at what point other groups can view
  our requirements comment?

16
Notes External Requirements (contd)

• 99.3 progress messages
• This is mostly covered by our use cases
• Well 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
• Well classify as additional meta-data that could
  be provdied with the SDD package.
• 99.5 admin privileges shouldnt 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?
• Well 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

17
Notes External Requirements (contd)

• 99.17 update and uninstall of shared components
• Good requirements but dont 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 whats 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

18
Notes External Requirements (contd)

• 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 hadnt 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 wont preclude any
  extra meta-data or content in a package.
• 153 SDD Extensions for ACS namespace elements
• Keisukes suggestion have xsdANY 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

19
Notes External Requirements (contd)

• 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 hadnt 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)

20
Notes, 11/16/2005
21
Notes External Requirements (contd)

• 99.13 licensing, contd
• Auditing and metering
• Another use case mapped to application identity
• Return receipt
• We wont preclude this
• Single-user license key
• We wont 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
• Weve forgotten what this meant will wait for
  Jay Nash
• Use case 123 component model
• This is covered by our other composition use
  cases
• However, weve 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

22
Notes External Requirements (contd)

• 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

23
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 Suns 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, dont force a
  revert
• Are there pieces which, once deployed, shouldnt
  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

24
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
• xsdANY?
• 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?