[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cosmos-dev] RE: CMDBf registration questions
|
Bill,
OK... I think I have a better understanding
of why you think of COSMOS acting "on-behalf" of the MDR. Specifically,
because our current client code is what kicks off the registration, the
rest of the MDR framework does not "know" about what it did.
To confirm we are both on the same page...
(and if I'm not, please continue to shape my head...)
As we worked through this on the call
earlier, that this was the part of the code that we need to refactor into
the "Registration Manager"/"Registration Helper" that
would become part of the MDR framework. The result is the second
set of steps that you outline below. I think that this essentially
means that ER 214672 becomes the way the user would interact with the "Registration
Helper". Does this make sense? And if so, does mean that
we can't support the "user selects multiple MDRs" for registration
and deregistration?
As an aside, I don't think this as a
new enhancement, but rather a continuation of the support we need to complete
on the other one that Ali used for the registration API.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing
| (919) 543 0625 | weitzelm@xxxxxxxxxx
|
| RE: [cosmos-dev] RE: CMDBf
registration questions |
| Muldoon, William H
| to:
| Cosmos Dev
|
02/06/08 02:57 PM |
| Sent by:
| cosmos-dev-bounces@xxxxxxxxxxx
|
| Cc:
| Ali Mehregani, Mark Johnson, Jacob Eisinger,
"Waschke, Marvin G", Troy
Volin |
Please respond to Cosmos Dev <cosmos-dev@xxxxxxxxxxx>
|
|
|
Mark
The external component that I referred to as COSMOS is the
COSMOS UI. So I really did mean to say that the COSMOS UI performs the
registration “on behalf” of the MDRs. Refer to the design page at http://wiki.eclipse.org/COSMOS_Design_214672.
For example, in the first scenario, an administrator is running the COSMOS
UI and “right clicks on a federating CMDBf”, selects the “register configuration
items” popup menu, selects the MDRs, and clicks register. Thus the registration
activity is initiated by the COSMOS UI. It’s NOT initiated by the MDRs.
We have this sequence:
1.
COSMOS
UI issues CMDBf queries to obtain CIs from the MDRs.
2.
COSMOS
UI invokes the CMDBf registration interface on the federating CMDBf using
the CIs from the previous step.
3.
COSMOS
UI receives the CMDBf registration responses but cannot do anything with
it.
4.
The
MDRs are left in the predicament of being unable to maintain the integrity
of the registration because they are unaware of the registration in step
2.
Today’s discussion included a new enhancement to provide
some “helper” plumbing to assist developers of COSMOS MDRs to support
CMDBf registration. In this case, the registration is initiated by the
COSMOS MDR. We have this sequence:
1. COSMOS
MDR invokes the CMDBf registration interface on the federating CMDBf using
the COSMOS “helper” plumbing.
2. COSMOS
MDR receives the CMDBf registration response and uses the COSMOS “helper”
plumbing to track the registration.
3. COSMOS
MDR detects a change to a registered CI and uses the COSMOS “helper”
plumbing to update the registration.
The “helper” plumbing provides
an added value in COSMOS for MDR developers. But this is a separate topic
than ER 214672.
As far as 214672 is concerned, let’s see what the CMDBf
folks have to say…
Regards
Bill
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark D Weitzel
Sent: Wednesday, February 06, 2008 1:21 PM
To: Muldoon, William H
Cc: Mark Johnson; Troy Volin; Ali Mehregani; Jacob Eisinger; Waschke,
Marvin G; Cosmos Dev
Subject: [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
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
