Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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: |
|---|---|---|
| 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.