FYI: Forwarding from Mark J.
From: Mark Johnson
[mailto:mwj@xxxxxxxxxx]
Sent: Thursday, February 07, 2008
1:20 PM
To: Muldoon, William H
Cc: Ali Mehregani; Feldman, Andrew
A; Jacob Eisinger; Mohsin, Jimmy; Waschke, Marvin G; Troy
Volin
Subject: RE: [cosmos-dev] RE:
CMDBf registration questions
Everyone,
(Feel
free to forward on to cosmos-dev)
Marv
and I had a side exchange and I'd like to sum up what is required by an
implementation of the spec. The CMDBf spec is intended to be useful across a
range of configurations, so I'm attempting to avoid too many subjective
statements.
- The expected behavior
defined in the spec (lines 1531-1536) is that once an MDR has
registered data using a given mdrInstanceId, it is expected to maintain
that data using the same instance ID, including deregistering the ID if it
is no longer valid. If it cannot do that, and wishes only to have its data
available for query, it should not use the registration service.
- The MDR must not make any
assumptions about whether data it sends with a new instance ID reconciles to
any data it sent previously. This is because the registration service may
not even have a reconciliation function, or it might be configured to not
perform reconciliation on certain types of data, or perhaps the data
itself has changed enough that the results of a reconciliation algorithm
yield different results, or any other reason.
- The freshness of the data
in the Federated CMDB depends on the capabilities of the F-CMDB and MDR
implementations and how they are configured. This applies to both push and
pull mode, though an MDR that pushes data is better positioned to initiate
an update immediately rather than a F-CMDB that periodically polls for
changes.
- Note that it is perfectly
acceptable for a registration client to periodically reregister all the data
that has been previously registered. If nothing has changed, including
potentially even the <recordMetadata>/<lastModified> element,
and the F-CMDB has not been corrupted, the registrations would be treated
as updates, which in this case don't change anything.
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
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
02/07/2008 09:59
|
|
To
|
"Waschke, Marvin G"
<Marvin.Waschke@xxxxxx>, Mark Johnson/Austin/IBM@IBMUS
|
|
cc
|
"Ali Mehregani"
<amehrega@xxxxxxxxxx>, "Feldman, Andrew A"
<Andrew.Feldman@xxxxxx>, "Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>, Jacob Eisinger/Austin/IBM@IBMUS,
"Mohsin, Jimmy" <Jimmy.Mohsin@xxxxxx>, Troy
Volin/Durham/IBM@IBMUS
|
|
Subject
|
RE: [cosmos-dev] RE: CMDBf registration
questions
|
|
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:
1.
In the i9 iteration, we
continue with 214672 as designed, resulting in an MDR that does not maintain
the integrity of the registration.
2.
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
