Solution Deployment Descriptor Face to Face

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 scope2. Deep dive on ambiguous use cases to see if they’re in scope3. 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?