COSMOS Design 215267

Provide support for adding a federating CMDB to COSMOS framework

This is the design for Bugzilla 215267.

Change History

Name:	Date:	Revised Sections:
David Whiteman	1/18/2008	Initial version
Ali Mehregani	1/18/2008	Completed design

Workload Estimation

Rough workload estimate in person weeks

Process	Sizing	Names of people doing the work
Design	1 week	Ali Mehregani
Code	2 weeks	Ali Mehregani
Test	1 week	Ali Mehregani/QA team
Documentation	3 days	Ali Mehregani
Build and infrastructure	0	N/A
Code review, etc.*	0	N/A
TOTAL	4 weeks and 3 days

'* - includes other committer work (e.g. check-in, contribution tracking)

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:

Term	Definition
MDR	management data repository
CMDBf	specification for a CMDB that federates between multiple MDRs [1]
federating CMDB	the CMDB that federates between MDRs, offering a common access point to clients and correlating identifying record data
CMDB	configuration management database

Purpose

We needs to add support for adopters intending to register a federating CMDB with COSMOS framework. This enhancement will include reusable code for adopters intending to provide a server/client side implementation of a federating CMDB.

Implementation details

There is already code in place for adopters to use when implementing an MDR. The following MDR plug-ins will be extended to provide support for a federating CMDB:

org.eclipse.cosmos.dc.mdr
org.eclipse.cosmos.dc.mdr.client
org.eclipse.cosmos.dc.mdr.common

Three additional plug-ins will be introduced, each of which will be an extension of its MDR counterpart:

org.eclipse.cosmos.dc.federating.cmdb
org.eclipse.cosmos.dc.federating.cmdb.client
org.eclipse.cosmos.dc.federating.cmdb.common

On server side two operations will be introduced:

• Register
• Deregister

On client side few variations of registration. All variations will also apply to deregistration:

• Registration based on a request
• Registration of all items/relationships of a set of MDRs
• Selective registration based on a CMDBf query on a set of MDRs

Test Coverage

Testing will be blocked by: https://bugs.eclipse.org/bugs/show_bug.cgi?id=214903. A set of JUnit tests will exercise the implementation. The tests will depend on an environment to be set before being executed. The environment will at least have one MDR along with a federating CMDB (implemented as part of 214903) registered. The list below describes the set of tests created as part of this effort:

Test Case1: Registration/Deregistration by Request

1. Register items/relationships of an MDR with federating CMDB using a registration request
2. Assert response is successful
3. Query federating CMDB for the set registered
4. Assert result contains expected items/relationships
5. Deregister items/relationships using a deregistration request
6. Assert response is as expected
7. Perform the same query on federating CMDB
8. Assert the result is null

Test Case2: Registration/Deregistration by Query

1. Register items/relationships of an MDR with federating CMDB using a query request
2. Assert response is successful
3. Query federating CMDB for the set registered
4. Assert result contains expected items/relationships
5. Deregister items/relationships by query
6. Assert response is as expected
7. Perform the same query on federating CMDB
8. Assert the result is null

Test Case3: All-inclusive Registration/Deregistration

1. Register items/relationships of all MDRs with federating CMDB
2. Assert response is as expected
3. Submit a query to federating CMDB to extract data originally belonging to multiple MDRs
4. Assert the result set is as expected
5. Deregister items/relationships of all MDRs
6. Assert response is as expected
7. Perform the same query on federating CMDB
8. Assert the result is null

Open Issues

All reviewer feedback should go in the Talk page for 215267.

---