Hi Marv and Mark J
Thank
you both for your quick responses!
Mark W & Cosmonauts
Given
the range of behavior from “crappy” MDRs to intelligent MDRs, I think
we should strive to produce MDRs that are on the more intelligent end of the
scale, correct? I propose the following approach:
- In
the i9 iteration, we continue with 214672 as designed, resulting in an MDR
that does not maintain the integrity of the registration.
- In
the i10 iteration, we implement a COSMOS specific MDR interface that
enables COSMOS MDRs to maintain the integrity of the registration. This
interface will be used by the COSMOS UI to update the internal registration
table of the COSMOS MDR. The “helper plumbing” will facilitate
this feature. In addition the COSMOS UI should issue a warning to the user
if the new interface is not supported.
As a
result, COSMOS MDRs will work well with the COSMOS UI registration feature but
non-COSMOS MDRs will receive warnings when used with the COSMOS UI registration
feature.
In the
future when the CMDBf spec supports notifications, we can deprecate the COSMOS
specific interface and use the future COSMOS Event Broker to support the CMDBf
notifications to maintain registration integrity.
Regards
Bill
From: Waschke, Marvin
G
Sent: Wednesday, February 06, 2008
6:34 PM
To: Mark Johnson
Cc: Ali Mehregani; Feldman, Andrew
A; Cosmos Dev; Jacob Eisinger; Mohsin, Jimmy; Troy Volin; Muldoon, William H
Subject: RE: [cosmos-dev] RE:
CMDBf registration questions
Comment below.
Marvin
Waschke
Senior Technology
Strategist
Service Management
Tel: +1 360
383 9022
Mobile: +1 425 269 5592
Marvin.Waschke@xxxxxx
Blog: Iterating on IT Service
From: Mark Johnson
[mailto:mwj@xxxxxxxxxx]
Sent: Wednesday, February 06, 2008
1:58 PM
To: Waschke,
Marvin G
Cc: Ali Mehregani; Feldman, Andrew A; Cosmos Dev; Jacob Eisinger; Mohsin, Jimmy; Troy Volin; Muldoon, William H
Subject: RE: [cosmos-dev] RE:
CMDBf registration questions
Marv, et. al.,
See
responses embedd using <mwj> this style.
</mwj>
Regards,
Mark
Mark W Johnson
Tivoli Advanced
Technology
CMDB Federation standard; ARM standard
IBM
512-838-0496 (office)
512-699-9105 (cell)
Mark Johnson/Austin/IBM
mwj@xxxxxxxxxx
|
"Waschke,
Marvin G" <Marvin.Waschke@xxxxxx>
02/06/2008
15:19
|
|
To
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>, "Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>
|
|
cc
|
Mark Johnson/Austin/IBM@IBMUS, Troy
Volin/Durham/IBM@IBMUS, "Ali Mehregani"
<amehrega@xxxxxxxxxx>, Jacob Eisinger/Austin/IBM@IBMUS, "Feldman, Andrew A"
<Andrew.Feldman@xxxxxx>, "Mohsin,
Jimmy" <Jimmy.Mohsin@xxxxxx>
|
|
Subject
|
RE: [cosmos-dev] RE: CMDBf registration questions
|
|
I will probably confuse things by asking more
questions than providing answers.
First, I think it is possible, although probably not desirable,
to maintain a push mode federation without the MDR ever getting any feedback
from the federating CMDB. Leaving COSMOS out of the picture for a second, the
steps go:
1.
MDR calls the fed-CMDB
to register an item with an mdrId of “MDR-A”, instanceId of
“1” and one reconciliation property <name>One</name>.
2.
fed-CMDB accepts the
registration and returns
<instanceResponse>
<instanceId><mdrid>MDR-A</mdrid><id>1</id></InstanceId>
<accepted/>
</instanceResponse>
3. MDR throws away the response
At this point the fed-CMDB has a record of an item with
name “One” and scoped instance id of “MDR-A 1” With
that knowledge, it can (if it wants to and the MDR has a query service) query
the MDR for its information on “MDR-A 1”. Alternatively, the
fed-CMDB can query for information on items with property “name”
equal to “One”. The only requirement on the MDR is that whenever it
responds to a query on “MDR-A 1”, it must reply with data on the
item it originally registered as “MDR-A 1”. In other words,
the only requirement on the MDR would be to never use “1” as the id
for any item but the item named “One”.
The MDR could, if it were sufficiently crappy, simply never
use “MDR-A 1” again and not answer queries on “MDR-A
1”. It could, if really crappy, even register the same item with a
different id, say “2”. That registration would be something like
this:
<registerRequest>
<mdrId>MDR-A</mdrId>
<item>
<record>
<name>One</name>
</record>
<instanceId><mdrId>MDR-A</mdrId><id>2</id></instanceId>
</item>
</registerRequest>
A sharp fed-CMDB would reply:
<instanceResponse>
<instanceId><mdrid>MDR-A</mdrid><id>2</id></InstanceId>
<accepted/>
<alternateInstanceId><mdrId>MDR-A</mdrId><id>1</id></instanceId>
</instanceResponse>
From which we can infer that the fed-CMDB reconciled both
registrations as referring to the same item.
<mwj> However, the MDR is obliged to report future
state changes to MDR-A:1 as well as MDR-A:2. The MDR must not assume that the
F-CMDB reconciles the items together. Whether it does is dependent on the F-CMDB
implementation, how it is configured (e.g., local policy *could* state never
reconcile anything with record type foo), etc. </mwj>
The point is that MDR-A can be as dumb as a post, paying no
attention to what it has done before and still play by the rules. It could,
rather than notifying the fed-CMDB every time an item which it has registered
has changed, just re-register periodically, not even bothering to use the same
instance id. Again, a crappy MDR, but sometimes, an MDR that is no more than a
few flat files on somebody’s desktop may be useful.
<mwj> I don't agree. If the F-CMDB returns
<accepted>, then the MDR is obliged to maintain the data for the
<mdrInstanceId> that it registered. It is not obliged to use the returned
CMDB:id. The ability for an MDR to continue using its own IDs removes a
potentially show-stopping requirement from the MDR. We expect that MDRs that
only use their own IDs will be common when existing products add an MDR layer
and don't want to do things like modify their database schema, etc. The CMDB:id
is returned because there were requirements from some MDRs to replace their own
ID with the official ID from the CMDB. </mwj>
[MW]
Why oblige the MDR to maintain the data for the <mdrInstanceId>? I can
see recommending that the MDR maintain a unique id and always register a
change with that <mdrInstanceId> when the MDR’s data on an item
changes, but requiring it? The system will work even if it is not
required—the data from a dumb MDR will always be somewhat suspect, but at
least it will be there. Data from a push model MDR that has no query service is
pretty shaky anyway. What if the MDR has been down for a week? Or just
unreachable? Unless you can query the MDR you will never be certain that the
registered data is not stale. </MW>
This is not to say that building helpers that
keep track of what is registered and help an MDR maintain the integrity of the
fed-CMDB would not be useful, only that dumb MDRs would not need them.
I have always thought that responsibility for the integrity
of the data falls mainly on the fed-CMDB through query services implemented by
the MDRs. For high integrity data, the fed-CMDB should always query the MDR or
MDRs when a request for data comes to the fed-CMDB. When a task being performed
by the user of the fed-CMDB requires speed at the expense of the risk of stale
data, then the fed-CMDB might only return whatever happened last to be
registered, and skip the query. There are lots of trade-offs possible, which is
a nice part of this architecture.
Mark Johnson—Speak up if I am all wet!
<mwj> OK. :-> </mwj>
Regards, Marv
Marvin Waschke
Senior
Technology Strategist
Service Management
Tel: +1 360 383 9022
Mobile: +1 425 269 5592
Marvin.Waschke@xxxxxx
Blog: Iterating on IT Service
From: Muldoon, William
H
Sent: Wednesday, February 06, 2008 11:52 AM
To: Cosmos Dev
Cc: Mark Johnson; Troy Volin; Ali
Mehregani; Jacob Eisinger; Waschke, Marvin G
Subject: RE: [cosmos-dev] RE: CMDBf registration questions
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
