Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
COSMOS SDD Minutes 14JAN08
Logistics
- Date: 14JAN08
- Time: 1PM EST
Agenda
1) Use case identification -- two areas of focus
* Install/uninstall simple application * Install/uninstall complex solution
Attendees
SAS: Jason Losh, Merrie Jensen, Jeff Hamm, Mark McCraw, Josh Hester, Robert DeMason
IBM: Chris Mildebrandt, Mark Weitzel, Charlie Halloran
CA: Jimmy Mohsin Jack Devine
Minutes
Working on logistics. Iteration 10 is March/end June. Need to identify any dependencies among the project. Q: What is scope of Use cases? Just installation of COSMOS components? A: Scope is package authoring tooling & runtime of CL1 of the SDD spec plus examples. Maybe including installing pieces of Eclipse depending on how we line up with P2. This needs to be extensible so it can be expanded to add CL2 support when resources are available.
Start with Tools
- 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.
- Separate use case: just introspect the artifact, especially in the case of a 3rd party component, and create as much of the SDD as possible.
- assume: 1 IU, LU, CU, and package descriptor per SDD. SDD means both, otherwise explicitly state it.
- Another use case: support for build systems beyond the popular rpn, msi, etc. so that metadata from those systems could be brought in.
- Need set of rules for assembling the metadata and resolving conflicts (same set of data with different values)
- As the SDD is being created, validate that what has been created is syntactically correct. You may want to turn validation on or off. A plug-in rules engine could also be useful to validate user extensions that are allowed by the validation process.
- Next step would be creating the actual package(Package Generation): SDD, artifact onto "media" that would make it consumable. May need to include in the packaging the SDD runtime and repository code.
- Tool must be able to be configured (where is data source, what rules are created, etc): basic administration of the tool parameters. For moving the tool for use in another department or product. These things will change: artifact inputs, location of SDD outputs, custom rules for creation and validation, SDD content constraints (per IU, CU, LU)
- Another use case is for a GUI front end to create and edit the SDD that could be initially created by the BTG, or created 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 Use Cases:
Two categories of applications: Non-Federated and Federated (whether it is exposed to a federated inventory kind of database or not).
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.
- Installing a Non-Federated application: requirements include a runtime to interpret that package (bootstrapped if not already there)and install the artifacts and registering the existence of the resource in a repository (create/initialize if not already there)and completion actions (reboot, start/stop service, cleanup).
- Uninstalling a Non-Federated application: Bootstrap & initialize repository if needed, then de-register the resource from the repository and remove the application, plus any completion actions.
- Configuring a Non-Federated application: requirements include a runtime to interpret that package (bootstrapped if not already there)and configure the artifacts and optionally registering the configuration of the resource in a repository (create/initialize if not already there)and completion actions (reboot, start/stop service, cleanup).
- Undo a Non-Federated application: Bootstrap runtime & initialize repository if needed, then remove the last level of update to the application, change the registration as needed, plus any completion actions.
- Updating a Non-Federated application: Bootstrap runtime & initialize repository if needed, then update the application, change the registration as needed, plus any completion actions.
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 above 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).
A valid use case is to be able to register in federated CMDB without requiring a re-install (for updating an already-installed application into the CMDB).
Action Items
- How to contribute code from both SAS and IBM? Mark/Charlie need to work with IBM IP Legal.
- To be a reference implementation there are some rules to abide by and we should document how much of CL1 we support within the reference implementation.