Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:COSMOS Design 208584"
| Line 5: | Line 5: | ||
# 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: <span style="color:blue;">A Federating CMDB must use one or the other mode and MAY use both.</span> 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. | # 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: <span style="color:blue;">A Federating CMDB must use one or the other mode and MAY use both.</span> 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. | ||
# 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. | # 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. | ||
| − | # propose breaking up the CMDBf definition into the following two entries: {|{{BMTableStyle}} | + | # propose breaking up the CMDBf definition into the following two entries: |
| + | {|{{BMTableStyle}} | ||
|- | |- | ||
|'''CMDBf''' | |'''CMDBf''' | ||
Revision as of 16:12, 5 December 2007
This is the talk page for COSMOS Design 208584.
Comments from Valentina Popescu:
- 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.
- 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.
- 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 |
- add to end of MDR definition "as defined by CMDBf"
- add to end of SML definition "as defined by ITIL"
- add to the beginning of 4 of the last 5 terms (except "CMDBf query") the word "COSMOS"
- change cmdbf.query modules definition to start with "The modules provided by COSMOS CMDBf framework"
Response to Valentina Popescu comments:
- 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.
- Agree, we should make it a separate work item
- will make this change, thanks
- will make this change, thanks
- will make this change, thanks
- 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.
- will make this change, thanks