Talk:COSMOS Design 214672

Ali's Comments

A well thought-out document. A few comments:

1) Under "All-inclusive registration" > step #2:

Displaying unregistered MDRs on the left and registered MDRs on the right will cause ambiguities and confusion. For example, if an MDR is partially registered, will it appear on the left or right side of the dialog? There is also no generic mechanism that allows for a query of registered/unregistered MDRs against a federating CMDB.

The dialog should just display all MDRs and allow the user to check the ones that they intend to register with the federating CMDB (i.e. the dialog should simply be a list of check-box entries with each entry representing an MDR)

<sheldon>The reason I'm using a dual list is to make the interaction easier. With a dual list the user just selects the mdrs they want to register and click add then click submit. It reduces the amounts of clicks. Maybe I should just have a list that the user can highlight. After the user would click submit and the highlighted MDRs will be registered.</sheldon>

2) The deregistration operation should be symmetric to the registration operation:

a) All-inclusive deregistration:

i) User right clicks on a federating CMDB and selects "Deregister Configuration Items"
ii) The same dialog used for registration will appear with a check-box list of MDRs
iii) User selects the MDRs that they wish to disassociate with a federating CMDB and selects "Deregister"
iv) All registered items of the selected MDRs will be deregistered with the federating CMDB
v) A dialog will appear displaying the status of the deregistration process

b) Partial deregistration of items:

i) User performs a CMDBf query on the federating CMDB
ii) In the tabular view displaying the result of the query, the user will be able to select a set of items > right click > and select deregister.
iii) The items are deregistered and the status is displayed to the user

<sheldon>Yes I agree</sheldon>

Hubert's Comments

• This enhancements is for providing a user interface for the federating CMDB, and for MDRs to do registration assuming a federating CMDB is present. Given our position that COSMOS will not provide an implementation federating CMDB, are we ok with the scope of this enhancement? I suppose we need a "simple federating CMDB" in order to demonstrate this enhancement. Will we give the false impression that we are providing a federating CMDB?
• The notion of a reconciliation taxonomy is central to the operation of federation. That is, we need the definition of deferated data model. We will need the definition of the reconciliation taxonmy to decide what data to accept or reject. Do we need a definition of a reconciliation taxonomy for this enhancement? If not, how do we mock up the functions of the federating CMDB.
• I don't understand the concept of an "All-inclusive registration". How do we get a set of all confiuration items and relationships? Data federation is about selectively propagating data that is used by multiple applications to the federating CMDB. I would expect the data in the federating CMDB is a small subset of the actual database managed by each application represented by an MDR. We need a mapping of application-specific data to the reconciliation taxonomy to decide which item and which attributes of the item need to be federated.
• Use of user interface: I can see how a user interface is useful for managing federating CMDB configuration (i.e. the setup of reconciliation taxonomy, the push/pull mechanism, sync-up intervals, etc.) The actual registration process should done in batch mode according to the mapping rule (the mapping of application data to reconciliation taxonomy). Doing registration on individual items as described in bullet #3 in the "Partial registration" section is unlikely, because it doesn't scale up.

Bill's comments

Sheldon's comments in bold

• In 4.1.1.1, 4.2.3.3, and 4.3.1.1 "User selects a CMDBf", how do we determine which Data Manager is actually a CMDBf? Do we use a Broker Service Group? This is being discussed in Bug 217515
• In "All inclusive registration/deregistration" of 4.1.2.2 and 4.3.2.2, how do we determine the list of MDRs which are registered with the selected CMDBf? There's no interface in the CMDBf spec that allows us to query the list of registered MDRs.In all inclusive registration the list will show all MDRs that the brokers are aware of. It does not need to know which MDR is already registered. This is to keep the design simple. For deregistering, it may be an issue unless there's a cmdbf query that can be sent to the federating CMDB to get all deregistered MDRs.
• In 4.1.4.4 (and 4.3.5.5), the status response view should display the "reason" element of a declined response.Yes it should
• A typical MDR probably contains a very large number of items. In the "all inclusive registration/deregistration", how shall we handle large numbers of items (which will have a long response time and a large response size)?I discussed this with the CMDBf folks and they are aware of this. However they still said that it was useful
• In the registration process, how do we update the MDR with the returned CMDBf registration IDs required for subsequent data change updates from the MDR? Refer to the CMDBf spec (lines 1531-1536):

1531  If the return status is accepted, the Registration service returns the ID
1532 that identifies the item or relationship within the Registration service.
1533 For accepted data, the MDR is expected to update the Registration
1534 service whenever any of the registered data changes. The specification
1535 does not stipulate how soon after the data changes the update must
1536 occur – this would typically be determined by local policy.

• The previous point also applies to the unregistration process: we have no interface to inform the MDR that the items have been deregistered. For this enhancement we may not want to tackle this. This should be an additional enhancement