Talk:COSMOS Design 208584

This is the talk page for COSMOS Design 208584.

Comments from Valentina Popescu:

1. I am not sure if this is a new change for 1.0 but I see that the query service and registration service is not required for an MDR. Note the occurrences of may in the intro to section 3.2 of the CMDBf 1.0 spec. That means that our MDR framework MUST allow MDR implementations without a query service defined (same for registration service). The spec says: A Federating CMDB must use one or the other mode and MAY use both. So a federating MDR can choose to use pull or push but must choose one or the other. It is not clear to me what happens when an MDR does not define a query service and the federating CMDB decides to use pull. It is also not clear from the spec what is normative (MAY uppercase) and what is not. I’ll send a note to the spec author and ask for clarification.
2. Re: the note to reviewers regarding section 6 of the CMDBf 1.0 spec, I propose to open a different request (enhancement) to deal with this new feature. The main reason is that the current enhancement deals with moving COSMOS CMDBf code from 0.9 to 1.0. This feature is optional (compliant implementations are not required to support it); we should aim to add this type of support to our own implementation, though this task is not a blocker for porting to 1.0. Note that this is also not trivial to implement.
3. propose breaking up the CMDBf definition into the following two entries:

   CMDBf	CMDB Federation Specification
   Federating CMDB	As defined by the CMDBf spec, a CMDB that federates data from multiple MDRs

4. add to end of MDR definition "as defined by CMDBf"
5. add to end of CMDB definition "as defined by ITIL"
6. add to the beginning of 4 of the last 5 terms (except "CMDBf query") the word "COSMOS"
7. change cmdbf.query modules definition to start with "The modules provided by COSMOS CMDBf framework"

Response to Valentina Popescu comments:

1. Good thoughts... it will be interesting to see what he says. The CMDBf 0.95 spec did not include the "may" wording. However, the new text might be just poorly worded to indicate that both can have it, and needs to be spelled out that there needs to be at least one query service somewhere. <am> I believe what's required/optional is detailed out in table 1 of section 3.2.2 </am>
2. Agree, we should make it a separate work item
3. will make this change, thanks
4. will make this change, thanks
5. will make this change, thanks
6. Instead of adding COSMOS to all those term names, I'd prefer to add a disclaimer such as this: "These definitions are not meant to be general definitions of these terms, but rather refer to how the terms are used within this design document as applied to COSMOS." It seems redundant in some of these cases to include the word "COSMOS" in the term.
7. will make this change, thanks

Comments from Ali Mehregani:

Very well done. The design document effectively summarizes the changes between 0.95 and 1.0.
Some comments:

1. Avoid using the term “CMDBf toolkit”. This is already a term that’s been reserved for a separate enhancement. “CMDBf modules” or “CMDBf libraries” is a better choice.
2. Regarding your question about the meta-data support: I believe it’s important to add support as part of this migration effort. There is very little that needs to be done. We only need POJO representations. This can be added as another module to the CMDBf modules.
3. Keep in mind that the semantics of the XPath expression in a CMDBf query has changed. In 0.95, the XPath expression was used as a selector that evaluated to either true or false. In 1.0, the content of the record element contained by an item template is determined by the evaluation of the XPath expression. See line # 1181
4. It may help to add a section that will list the changes required for each CMDBf module. This will help break down the tasks into more granular actions.
5. Task 10 will require updating the document as well.