Talk:COSMOS Use Cases

A few thoughts heading into tomorrow’s discussion, re: use cases. Many items on the list read more like enhancement requests than use cases. What we need to focus on is the higher order function we are providing with COSMOS. Here is a pass at incorporating your thoughts:

Use Case: Enable a management application to federate its data via CMDBf interfaces. Description: This use case describes how a developer would adapt an existing collection of management data for use with a federating CMDB using the COSMOS framework. Actor: Developer Assumptions:

• The developer has downloaded the COSMOS framework and setup a development environment

This would cover 2.1.1 because the developer will need to build the handlers based on their data model. Using COSMOS, this will be the data center example. If this consistent with what can be used by commercial vendors in their federating CMDBs than that’s even better. We have an open ER to update the DataCenter model to the latest version of SML and could also use this to make any changes we want to support our use cases.

205826: Update DataCenter model based on latest SML changes https://bugs.eclipse.org/bugs/show_bug.cgi?id=205826

I think this also covers 2.1.3. We should detail out the steps that the developer would need to follow for a relational backed store. I think this should be detailed as part of:

209987: Create an example CMDBf Management Data Repository backed by a relational database https://bugs.eclipse.org/bugs/show_bug.cgi?id=209987

Also includes 2.1.6.

Details are here: http://wiki.eclipse.org/Providing_a_CMDBf_Query_and_Registration_Service

Other comments: 2.1.4 is statement of which platforms we will support and to me is more of a deployment use case.

Use Case: The System Deployer Configures Deploys an MDR onto Linux.

2.1.5: Two takes on this: A) This is what a federating CMDB will do and so we won’t likely address it. B) This is making the domain available in a widely distributed environment. If it’s B, then it a deployment use case. The different languages is a twist. For right now, I’d say that we need to restructure the ideas in this use case and it’s probobaly not an i9 item.

2.l.7 This sounds like a non-functional requirement we should address somewhere, but really isn’t a use case. We should be able to clearly articulate the advantage of using a DataManager vs. a “native” API. For example, the addition of a Web service interface or a more abstract interface et…

2.1.8: Non functional requirement

2.1.10: Should be the same as 2.1.9, registering an MDR.

2.1.13 should be included with 2.1.12

2.1.14: Yes. We need to describe this since there is not much in the spec about it now.

2.1.15: This could be part of 2.1.14, however, I think the query of metadata is more relevant than the broadcast.