Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

COSMOS Design 214903

Revision as of 10:45, 28 January 2008 by Unnamed Poltroon (Talk) ('''Change History''')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Provide a mechanism for testing the registration service and client

This is the design for Bugzilla 214903.

Change History

Name: Date: Revised Sections:
David Whiteman 1/21/2008
  • Initial version
Ali Mehregani 1/22/2008
  • Completed the design

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.5 week Ali Mehregani
Code 1.5 weeks Ali Mehregani
Test 0 Ali Mehregani/QA team
Documentation 0 N/A
Build and infrastructure 0 N/A
Code review, etc.* 0 N/A
TOTAL 2 weeks

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


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


A mechanism is needed to test functionalities that require the presence of a federating CMDB. The purpose of this enhancement is to create a simple version of a federating CMDB that can be used for testing some functionalities. This will only be included in the example module and won't appear as part of COSMOS' code base. The sample is for development purposes only and is not suitable for a production environments.

Implementation details

The new module, org.eclipse.cosmos.example.federating.cmdb, will be created under <HEAD>/org.eclipse.cosmos/examples. The example will implement the registration/deregistration service using a configuration file that contains all supported record types. The registration service will reject any records whose types are not found in the configuration file. The deregistration service will reject any records that have not previously been registered.

Test Coverage

This enhancement will indirectly be tested by functionalities that make direct use of the sample implementation of the federating CMDB (e.g. 215267). In addition, a simple test will be created for this implementation to guard against regression errors, due to the importance of having this test harness functioning properly.

Open Issues

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

Back to the top