Leveraging CMDBf

COSMOS Project Home > COSMOS Wiki > COSMOS Documents > COSMOS architecture

This page is the beginning of where we can begin our discussions on the CMDBf specification.

Documents

1. The CMDBf specification can be found here: http://cmdbf.org/
2. The CMDBf Interoperability Workshop Scenarios: http://wiki.eclipse.org/images/d/d2/CMDBf-Interop-Workshop-v0.31.zip
3. COSMOS CMDBf Deliverables: http://wiki.eclipse.org/images/b/b3/Cmdbf-cosmos-deliverables-v0.07.zip
4. CMDBf Query Service: http://wiki.eclipse.org/Providing_a_CMDBf_Query_and_Registration_Service

Overview

The COSMOS project intends to produce a reference implementation of a CMDBf Management Data Repository (MDR). The project will demonstrate how a client can use multiple MDRs through the CMDBf query interfaces and registration services to display information from multiple management systems. COSMOS will also create any additional infrastructure required to support the basic use case.

• Chris to update this section with business value and function positioning relative to commercial products

Basic End to End Use Case

The image below is an overview of the most basic use case.

Requirements

These are the high level requirements necessary to complete the implementation of CMDBf. We will break these down into bugzilla enhancement requests.

(Needs to be expanded on during the call... this is just a start....)

• Query
  • Implement the CMDBf as a Muse capability. Bind to the CMDBf API
  • Start on Binding to Ali's API
  • Map CMDBf query to convenience APIs for SML repo, Stat repo, and CBE repo (this is the data set issues)

• Registration
  • How do we reconcile the registration of MDRs vs. the item relationship
  • Do we need registration in the first round? Start with a focus on Query.
• Data Broker 197867: Need to design and implement the COSMOS DC Data Broker for i6
• WS-RC 198553: Provide an implementation of WS Resource Catalog
• Client updates 197870: Need to design and implement the COSMOS DC client APIs
• UI work for sheldon
• Reconcilliation
  • Need to make sure that the IDs line up or that we have only simplistic means of aligning the different resources
  • This gets into a bit of the taxonomies. May need simplistic mappings.
• MDRs look like Data Managers

• DataBroker/ProviderRegistry as MDR

Based on a discussion of the proposed DataBroker design, it appears that what is desired is a combination of an EPR registry for locating DataManagers and a repository of existing data sets that can be processed by those DataManagers. From the use case described above, it appears that the ProviderRegistry should act as an MDR to surface its knowledge of datasets and there attached metadata. If we are going to adopt the CMDBf query dialect as our lingua franca for communicating topology/metadata type information, then it makes sense to apply the CMDBf query capability to both the topology repository and the SDMX-style dataset/keyset repository of the ProviderRegistry.

Notes

The Data Broker is intended to be a simple component.

• Clarification of Registration v. Query (Push vs. Pull).
• MDR Negotiation: The handshake b/t the MDR and the Broker in order to facilitate Pull

• Need to outline the use case of bootstrapping the MDR with the management domain.

File:Dcframework2.zip

Ali and David's design is here-->COSMOS_Design_200222

Notes from 8-31 call

Want to have pluggable reconcilliation. Define an "idResolver interface"

• Want to have CMDBf query APIs in front of the data broker
  • Need to provide example of what is returned from the query, e.g. the graph query result
    • We'll need the EPR of the MDR, maybe some way to determine how to build a query for the MDR

• Data Broker becomes an internal implementation detail of the ???

• Break down the cmbdf query green box to separate the web services part
  • Break down the web services into the muse capabilities

• We will use the registration APIs to add things into the data broker
  • But may only accept queries about what we know about

• The data broker is not going to have relationships initially.

• Who has data about "server 33"?

In the interest of time, don't worry about the ws-rc APIs on the broker

COSMOS is an enablement technology for MDRs. COSMOS provides helpers, et. for federating CMBDs.

• Picture Updates.....

1. Change MDR2 to be "Asset Data"
2. Add a third MDR, call "Monitor Data".

• • No green query box. Yellow registration box

1. Add a CMDB (not implemented in COSMOS). Indicate that this is a federating CMDB. Would like to try and show reuse of the COSMOS helpers

• Add CMDBf query on the CMDB box. It takes care of the reconciliation. We ASSUME in COSMOS that ID reconciliation is done.

Next Steps

• Coordinate w/Ali the work that needs to be done
• Figure out how to make the CMDBf Web service gorp
• Provide examples of what needs to flow into the registration service
  • Update data broker to handle this new info
• Chris update overview section of this page

Open Issues/Questions

• Do we want the data broker to have CMDBf APIs on it?
• What value will an adopter derive by utilizing this use-case? (Jimmy Mohsin)
• What is the definition of exact deliverable, i.e what is in the final release package for this use case? (Jimmy Mohsin)
• What are the design / implementation pre-requisites for implementation of the CMDBf use case (Jimmy Mohsin)
• Will this use case result in one ER or multiple, i.e. how will the work be divided? I hope MULIPLE! (Jimmy Mohsin)
• How many resources are envisioned to be utilized and from which companies? (Jimmy Mohsin)
• What is the estimated time scope in weeks AND iterations (i7? i7 & i8?) (Jimmy Mohsin)
• Who will define the quality metrics and by when? (Jimmy Mohsin)
• We need clear (and timely) timeframes for design completions. (Jimmy Mohsin)

---

• Discussion of end-to-end CMDBf use case (Jimmy Mohsin has added the following sub-items)

** Pre-requisites for implementation for the CMDBf use case
** Will this result in one ER or multiple, i.e. how will the work be divided?
** How many resources are envisioned and from which company?
** Definition of exact deliverable
** Estimated time scope in weeks AND iterations (i7? i7 & i8?)
** Definition of quality metrics
** Clear timeframes for design completions

---