Difference between revisions of "Talk:COSMOS Design 200222"

Revision as of 14:01, 31 August 2007

This page includes all the discussion for COSMOS Design 200222.

[Valentina Popescu comments]

1. Re: SML Repository term: Shouldn't this be called COSMOS SML Repository to differentiate between this specific SML rep and a generic one ?
2. 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?
3. 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.
4. 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
5. 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:
   1. the user will have to understand the Data Center data types, or at least the ones that are made available for query
   2. 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

[Joel Hawkins comments] The Architecture diagram doesn't show the Property Subset directive implementation - it might be nice to pencil it in.

[Sheldon Lee-Loy comments]

1. Would it be possible to provides examples how items, facets and properties are modeled in the GraphQuery response. This will give the client a better understanding how to consume the response.
2. I'm also wondering how references are modeled in the graph query. If you have a SML facet that references an item will the reference contain an itemTemplate id? This will allow the client to construct a CMDBf query to get the reference items.
3. From the CMDBf spec it seems that I can only query for items from the repository. In which case the response will always be a list of items. Therefore I assume that graph response will contain a list of items that contain its nested facets and properties. If an item references another item the client would have to make another query. Is this correct?

[Replies to comments]

• Re: Valentina's comment #1, I changed the text preceding the list of terms to indicate that this is regarding how the terms are used in this document. I.e. when we refer to SML repository in this document, we mean the COSMOS one.
• Re: Valentina's comment #2, I deleted the term from the list, since it really was outside the scope of this design
• Re: Valentina's comment #3, this is something that should be considered down the road after i6. It doesn't fall under the scope of 200222. COSMOS does not intend to provide an implementation of a federating CMDB within i6.
• Re: Valentina's comment #4, the convenience APIs are just an alternative way of querying for data. I do agree that they will likely be deprecated when CML comes out but I have no intention of removing or deprecating them at this point.
• Re: Valentina's comment #5, it is true that the COSMOS client will be tied to the data center examples; however the query service does not make any assumptions about the type of data stored in the SML repository. I don't agree with adding a description that would imply a tight coupling between the implementation of 200222 and the data center example.

• Re: Sheldon's comment #3, I believe what you want is a <propertySubsetDirective>, which only returns properties instead of full items. Also you can exclude other items or relatinoships by using a dropDirective.