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 Design 215267
Contents
Provide reusable modules for consumers intending to provide a registration client
This is the design for Bugzilla 215267.
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Ali Mehregani, David Whiteman | 1/18/2008 |
|
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | unknown | Ali Mehregani |
Code | unknown | Ali Mehregani |
Test | unknown | TBA |
Documentation | unknown | TBA |
Build and infrastructure | unknown | TBA |
Code review, etc.* | unknown | TBA |
TOTAL | unknown | TBA |
'* - 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 |
Purpose
In the presence of a federating CMDB, adopters need to provide a registration client that will register all items/relationships of an MDR with a federating CMDB. Given this is common to all MDRs, it should reside in the data collection as a module that is reusable by COSMOS consumers.
The module can also provide the capability of selective-registering, where only a subset of the items/relationships contained by an MDR is registered with a federating CMDB.
Requirements
list any blocking ERs here.
Implementation details
TBD
Test Coverage
list test cases here.
Open Issues
This task is still being scoped.