Difference between revisions of "Talk:COSMOS Design 200222"

Revision as of 11:10, 28 August 2007

[Valentina Popescu comments]

• Re: SML Repository term: Shouldn't this be called COSMOS SML Repository to differentiate between this specific SML rep and a generic one ?
• Re: Service description term: How exactly are supported record types defined? Is there a configuration file where SML record types to be used by the Query Service are logged ? Or every SML type defined by the Data Center is required to be supported?
• Re:'The output of the query will also be in XML format, which the client is expected to understand.' I had a discussion with Ali today and went over what a client can and should understand from a CMDBf query. In summary : a CMDBf query is defined using the CMDBf query language ( the query set, containing one or more templates, etc ). This is part of the CMDBf spec and yes, it is straight forward that it is expected to be understood by the client initiating the query. But this is not enough to create a query. Aside of the CMDBf query language, which allows the user to format a query request, the actual 'content' of the query should use some sort of contract or understanding between the client and the Query Service implementor. So, for example, if a client defines a CMDBf query containing a template (I forgot the exact CMDBf naming for this.. ) asking for a 'user' element, the QueryService implementation should be able to map this 'user' with a type in the MDR's data source. It should know that when the query asks for a 'user', the MDR should actually get back all records with type = 'employee' ( user would map to an employee in this specific MDR. I think the way to achieve this is by having a common set of types at the federating CMDB level, and have all MDR's/QueryServices know about these types and know how to map their specific data to/from this generic types. We can start by defining this common types as being a subset of the current COSMOS SML Data Center Repository ( we can choose for example only machine, vm and os ); we should aim to have the common types be the CML library, once one is made available. Ali can probably explain all this in more detail.
• Re: SML repository convenience APIs: I don't think keeping the existing API's as an alternative to the QueryService will be a long lasting option; it should stay until COSMOS moves to CML. Once the COSMOS Data Center types will be replaced by a CML library type, these API's will cease to be as useful as they are now; the scope of the data will be extended to more than just machines, os, etc; it may be hard for the API to satisfy this extended spec
• Re: Requirements: It is implied from the usecases section that the clients will be only able to query the COSMOS Data Center repository. We should make this clear here; I understand this is how much will be delivered in i6 and I am okay with this but we need to clearly state it so we don't loose track of the fact that we address only this part of the puzzle. The implications for this restriction:
  • the user will have to understand the Data Center data types, or at least the ones that are made available for query
  • if not all the DataCenter types are planned to be made available for query, the MDR/Query Service will need a mechanism for registering the types it wants to make available; the user must know about this registration and must understand the content of the registry to the point where he can create a query using those types.

What needs to be done post i6:

• • build a generic, common set of types a client can use to define a CMDBf query. This common type can be registered at the federation level; the common type should ideally be a subset of CML or the Data Center types
  • every MDR/Query Service will know how to map its data to/from these common types
  • a client will know how to create a query to address to the CMDB federation using these types; will know how to read the result, again containing common type-based information