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 200222
Contents
- 1 Adding support for the CMDBf query service on top of the SML repository
- 2 Workload Estimation
- 3 Terminologies/Acronyms
- 4 Purpose
- 5 Requirements (required)
- 6 Use Cases (required)
- 7 Graphical Layout (optional)
- 8 Class Diagram and Implementation Details
- 9 Class Diagrams (optional)
- 10 Extension Points (optional)
- 11 Test Coverage (required)
- 12 Task Breakdown (required)
- 13 Open Issues/Questions
Adding support for the CMDBf query service on top of the SML repository
Change History
Name: | Date: | Revised Sections: |
---|---|---|
David Whiteman | 8/21/2007 | Initial version |
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | 1 | David/Ali |
Code | 2 | |
Test | 1 | |
Documentation | 0.4 | |
Build and infrastructure | 0.2 | |
Code review, etc.* | 0.2 | |
TOTAL | 4.8 |
- - 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:
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 |
SML Repository | repository of SML documents hosted in COSMOS with an established API (see bugzilla 179828) |
Query service | MDRs make data available to Clients via a Query service. Queries may select and return items, relationships, and/or graphs containing items and relationships. |
Service description | Description of query service supplied to the federating CMDB. This includes ID, descriptive text, supported record types, and other capabilities |
Purpose
According to the CMDBf specification, a repository will need to provide two services for it to be considered as an MDR:
- Registeration
- Query
The implementation of these services is the minimum requirement for a repository to be integrated with a federating CMDB. During the i6 time-frame a query service will be implemented for the SML repository. The service will allow clients to query the available data with the XML query language detailed out in the CMDBf specification. The output of the query will also be in XML format, which the client is expected to understand.
Currently clients are expected to interact with the SML repository via a set of convenience APIs. This enhancement does not imply the removal of such APIs. They may need to slightly be modified to accompany the new changes but they can still be reused by clients who have no intentions of leveraging the new query service.
There will likely be common set of code between the COSMOS client and the SML repository. It's expected that this common set will reside under the data collection subproject. One of the primary objectives of this document is to identify this reusable set of common code.
Requirements (required)
The necessary functionality will be:
- A service description for the federating CMDB to uniquely identify the MDR
- A single operation called GraphQuery that answers a graph of the items and relationships that satisfy the constraints of the graph in the query
- A facility to translate the graph query to the syntax expected by the SML repository API
- A facility that converts the results of the SML repository API call to the graph format expected to be returned by the GraphQuery operation
Use Cases (required)
Use Case 1: (can we just point to section 4.4 of the CMDBf spec as our use case?)
Graphical Layout (optional)
Class Diagram and Implementation Details
Class Diagrams (optional)
<This section is only required for features that are introducing APIs that will be leveraged by other components>
Extension Points (optional)
<This section should only be included if new extension points are being introduced>
<Include any additional topics that will help in completing the implementation>
<Content related to the topic above>
Test Coverage (required)
<Include a description of the unit, functional, and system test cases that will be required to test the overall quality of the feature>
- We will need a test that makes the same kind of pull request to the MDR as if it were a federating CMDB. The assumed contents of the SML repository will be the data center example.
Here is a graph query that can be used for a unit test, to retrieve all computers that have an installed OS with a brand name of "Red Hat 8":
<query> <itemTemplate id="software"> <propertyValueSelector namespace="http://www.cosmos.rm/dataCenter/os" localName="brand"> <equal>Redhat 8</equal> </propertyValueSelector> <recordTypeSelector namespace="http://www.cosmos.rm/dataCenter/os" localName="WHAT GOES HERE?"/> </itemTemplate> <itemTemplate id="computer"> <recordTypeSelector namespace="http://www.cosmos.rm/dataCenter/machine" localName="WHAT GOES HERE?"/> </itemTemplate> <relationshipTemplate id="runsWithOS"> <recordTypeSelector namespace="http://www.cosmos.rm/dataCenter/machine" localName="WHAT GOES HERE?"/> <source ref="computer"/> <target ref="software"/> </relationshipTemplate> </query>
Question: relationship labels don't exist in the SML repository. Do these have to have any significance?
The resultant graph should be as follows:
something something