[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cosmos-dev] RE: CMDBf registration questions
|
Bill,
I think we went into some good detail
on the cosmos call this morning. I'm copying Mark J. and some other
members of his team on this note so that when Ali updates the design page
to capture our thoughts, they. can reference this thread.
Where I think COSMOS can help is to
establish some of the APIs as part of the programming model, for adapting
existing stores of management data to MDRs. From the perspective
of the CMDBf spec people, this could easily be "an implementation
detail". However, as we think about how and where work in the
open can provide value, this kind of "registration management"
could add significant value. It feels like plumbing everyone will
need to build.
There might also be something very subtle
in your mail below. When you apply the COSMOS MDR code on top of
an existing data store, this IS the MDR. It is how you do federation.
So COSMOS does not initiate federation "on behalf" of an
MDR b/c it IS the MDR. Part of the "binding" to an existing
data store is the "callback" interface that can hook into the
pull mode.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing
| (919) 543 0625 | weitzelm@xxxxxxxxxx
|
| RE: CMDBf registration
questions |
| Muldoon, William H
| to:
| Mark D Weitzel, Ali Mehregani
|
02/06/08 09:55 AM |
| Cc:
| "Hubert H Leung",
"Sheldon Lee-Loy", "Cosmos Dev", "Waschke, Marvin
G" |
|
|
|
Mark
I think all of us have the same interpretation of the CMDBf
spec. The CMDBf spec defines the push mode, where the MDR initiates the
federation and the pull mode, where the CMDBf initiates the federation.
In both modes, the initiator is responsible for maintaining the integrity
of the registration. In the implementation of the initiator (MDR or CMDBf),
it must maintain an internal list of registered items. When any of the
registered items in the internal list change state, it is responsible for
updating the registration.
The issue is that we are trying
to implement a third mode, where an external component (COSMOS) initiates
the federation on behalf of an MDR acting in push mode. The problem
is that the MDR has no idea that COSMOS initiated the federation and thus
cannot update its internal list of registered items.
One solution is that the external
component (COSMOS) informs the MDR of the registration so it can update
the internal list of registered items and continue with business as usual.
Unfortunately there is no such interface for the MDR in the CMDBf spec.
This was the point of my original question.
Another solution is for COSMOS
to maintain an internal list of registered items, perhaps in a Notification
Broker component as you suggested. But today, this component must use polling
to determine if any of the registered items change state and a polling
solution is not really desirable. A better solution is to use events. But
again there is no such event interface for the MDR in the CMDBf spec.
I’ve included cosmos-dev and Marv for his opinion.
Regards
Bill
From: Mark D Weitzel [mailto:weitzelm@xxxxxxxxxx]
Sent: Wednesday, February 06, 2008 9:36 AM
To: Ali Mehregani
Cc: Hubert H Leung; Sheldon Lee-Loy; Muldoon, William H
Subject: Re: CMDBf registration questions
I also interpret the spec the way Ali has. I think of CMDBf as a
point-to-point protocol. An MDR knows about a federating CMDB. The
registration API is used for these updates/deregistration. We should
have what we need today based on Ali's work. Technically, an MDR
can, know about more than one, but as Ali points out, there is no broadcast
mechanism, so an MDR is always sending one message at a time to a cmdb.
Any discussion of a notification broker should be taken off the table
until we get some insight from the CMDBf group. At a minimum, it's
an i10 item, if then.
Lines 1544 - 1549
o The MDR also uses the Register operation to
update registered data. An update may consist of any combination of:
o Changes to existing data, such as a property
value change
o Registering an additional record type for
this item or relationship
o Deregistering a previously registered record
type for this item or relationship
p.s. Is there any reason this thread is not on COSMOS-Dev?
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing
| (919) 543 0625 | weitzelm@xxxxxxxxxx
|
|
| Re: CMDBf registration
questions Link |
| Ali Mehregani
| to:
| Sheldon Lee-Loy
|
02/05/08 05:59 PM |
| Cc:
| Hubert H Leung, Mark D Weitzel,
"Muldoon, William H" |
| |
|
Here's my translation of the section copied from the specification (lines
1531-1536):
When MDR registers item A and A is accepted by the federating CMDB, then
it is the responsibility of the MDR to notify the federating CMDB when
A changes. E.g. if A is deleted from the MDR, then it is the responsibility
of the MDR to notify the federating CMDB that A has been deleted.
I'm not sure why you're asking how we can update the MDR with the registration
IDs.
There are no plans in i9 for MDRs to broadcast changes to items/relationships
that have been registered with a federating CMDB. This will be enable
once we have an implementation of a notification broker.
I'm confused by the second question as well. I don't think we have
the same interpretation of the section that's been copied from the specification.
Ali Mehregani
Phone Number: (905) 413-3712
Service Modeling Language - COSMOS
http://www.eclipse.org/cosmos/
| Sheldon Lee-Loy/Toronto/IBM
05/02/2008 04:44 PM
|
|
To
| "Muldoon, William H"
<William.Muldoon@xxxxxx>
|
|
cc
| Mark D Weitzel/Raleigh/IBM@IBMUS, Ali
Mehregani/Toronto/IBM@IBMCA, Hubert H Leung/Toronto/IBM@IBMCA
|
|
Subject
| Re: CMDBf registration questionsLink |
|
Hi Bill,
I replied to your questions on the talk page.
Mark,
Bill pointed out a good point.
- 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
Do we have the interfaces in place to update the MDRs?
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Tivoli Autonomic Computing, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610
| "Muldoon, William
H" <William.Muldoon@xxxxxx>
02/05/2008 03:13 PM
|
|
To
| Sheldon Lee-Loy/Toronto/IBM@IBMCA
|
|
cc
|
|
|
Subject
| CMDBf registration questions |
|
Sheldon
Please
see my comments on
the talk page at
http://wiki.eclipse.org/Talk:COSMOS_Design_214672.
Thanks
Bill
