Revision as of 17:58, 21 January 2008

Overview

This is the working area for the definition of the COSMOS Use Cases for SDD.

When complete, the use case will be moved to the COSMOS Use Cases page and incorporated into a milestone.

All use case definitions should follow the guidelines described on the COSMOS Use Cases.

Elaboration of Use Cases

Use Cases for Deployment

Use Case 1: Install new software
Description: A system administrator/end user installs an application into a development/testing/production environment
Actor(s): System administrator/end user
1. The administrator/end user invokes the install process
2. The install process initializes a runtime/management data repository service or API
3. The install process interrogates the environment for system requirements
4. Th administrator/end user completes install interview questions -- this may be wizard based in a windowing environment, a text interface in a non-windowing environment or by response file in a batch/provisioned environment
5. The install process determines artifacts to be installed based on requirement checks and interview questions
6. The install process copies selected artifacts to the system
7. The install process runs post-copy steps/configuration
7. The install process registers the change with the MDR service/API
8. The install process performs any completion actions (reboot, restart, etc.)
9. The administrator/end user exits the install process
10. The install process performs appropriate system cleanup -- removal of temporary files, etc.

Use Case 2: Uninstall software
Description: A system administrator/end user uninstalls an application from a development/testing/production environment
Actor(s): System administrator/end user
1. The administrator/end user invokes the uninstall process
2. The uninstall process initializes a runtime/management data repository service or API
3. The uninstall process interrogates the environment for system requirements
4. Th administrator/end user completes uninstall interview questions -- this may be wizard based in a windowing environment, a text interface in a non-windowing environment or by response file in a batch/provisioned environment
5. The uninstall process determines artifacts to be uninstalled based on requirement checks and interview questions
6. The uninstall process removes selected artifacts from the system
7. The uninstall process runs post-removal steps/configuration
7. The uninstall process registers the change with the MDR service/API
8. The uninstall process performs any completion actions (reboot, restart, etc.)
9. The administrator/end user exits the uninstall process
10. The uninstall process performs appropriate system cleanup -- removal of temporary files, etc.

Use Case 3: Configure software
Description: A system administrator/end user configures an application in a development/testing/production environment
Actor(s): System administrator/end user
1. The administrator/end user invokes the configuration process
2. The configuration process initializes a runtime/management data repository service or API
3. The configuration process interrogates the environment for system requirements
4. Th administrator/end user completes configuration interview questions -- this may be wizard based in a windowing environment, a text interface in a non-windowing environment or by response file in a batch/provisioned environment
5. The configuration process determines artifacts to be installed and configured based on requirement checks and interview questions
6. The configuration process configures the selected artifacts
7. The configuration process runs post-configuration steps
7. The configuration process registers the change with the MDR service/API
8. The configuration process performs any completion actions (reboot, restart, etc.)
9. The administrator/end user exits the configuration process
10. The configuration process performs appropriate system cleanup -- removal of temporary files, etc.

Use Case Definitions -- notes from 1/14 discussion

Tooling Use Cases
1) Use case: normal development creates artifacts which reside somewhere. Need to create SDDs for these artifacts based on the build information. Build information can be metadata somewhere or introspected from the artifact itself.
2) Separate use case: just introspect the artifact and create as much of the SDD as possible. This is useful especially in the case of a 3rd party component, where the build information is not available.
3) Support for build systems beyond the popular rpn, msi, etc. so that metadata from those systems could be brought in.
4) Need a set of rules for assembling the metadata and resolving conflicts (when the same set of data occurs with different values)
5) As the SDD is being created, validate that what has been created is syntactically correct. Validation may be turned on or off. A plug-in rules engine could also be useful to validate user extensions that are allowed by the validation process.
6) In addition to SDD creation, there is a use case for creating the actual package(Package Generation): SDD and artifact onto "media" that would make it consumable. May need to include SDD runtime and repository code in the packaging.
7) Tool must be able to be configured (where is data source, what rules are created, etc): basic administration of the tool parameters. For example, when moving the tool for use in another department or product. These things will be configurable:

• artifact inputs
• location of SDD outputs
• custom rules for creation and validation
• SDD content constraints (per IU, CU, LU)

8) Need a GUI front end to create and edit the SDD that has been initially created, or create one from scratch. GUI tool could also need the options to validate, package and deploy. Such a front end would need the same kind of location definitions and constraint administration to allow or disallow parts of the SDD that are "editable".

Deployment
Background: There are two categories of applications: Non-Federated and Federated (whether it is exposed to a federated inventory kind of database or not). For Federated Applications: need Web Services port open, take CMDBf graph queries and give replies about the MDR.
Assumptions: No way to know if a federated CMDB is accessible or not. But if it is, need to query it and write to it. Using the federated CMDB is the extra step in the below use cases for the federated case. Which repository to use should be transparent to the install program as much as possible, it should be handled by the runtime based on a configuration setting or documented install parm (e.g., CMDBf = True, CMDBServer=ipaddr).
The install target can be one of: Test/Development, Production, Hardened.
Requirement to run from media is supported by OASIS use cases 14, 15, 192.
What format is required for the repository? SML? Single MDR for the non-federated case that represents all software on the system? Store is not as important as being able to get the right info in and out of it.

Deployment Use cases:
1) Installing a Non-Federated application: include a runtime to interpret the package and perfrom these tasks:

• bootstrap the runtime if not already there
• install the artifacts
• register the existence of the resource in a repository (create/initialize if not already there)
• completion actions (reboot, start/stop service, cleanup, etc.).
  

2) Uninstalling a Non-Federated application: perform these tasks

• bootstrap the runtime if not already there
• de-register the resource from the repository
• remove the application
• completion actions (reboot, start/stop service, cleanup, etc.)
  

3) Configuring a Non-Federated application: perform these tasks

• bootstrap the runtime if not already there
• configure the artifacts
• register the configuration change in a repository (create/initialize if not already there)
• completion actions (reboot, start/stop service, cleanup, etc.).
  

4) Undo a Non-Federated application: perform these tasks

• bootstrap the runtime if not already there
• remove the last level of update to the application
• change the registration as needed. Undo only applies to an update to a resource, not a configuration.
  
• completion actions (reboot, start/stop service, cleanup, etc.)
  

5) Updating a Non-Federated application: perform these tasks

• bootstrap the runtime if not already there
• update the application
• change the registration as needed.
• completion actions (reboot, start/stop service, cleanup, etc.)
  

6) Be able to register in federated CMDB without requiring a re-install (for updating an already-installed application into the CMDB).