RE: [cosmos-dev] question on management domain and brokers

[Mark D Weitzel <weitzelm@xxxxxxxxxx>]

In the thread below, it seems like several
distinct things are going on.  I'll try to comment on some of the
threads here.  Let me know if I'm crazy.


<<Hmmm. Well, if we can
assume that the MD and the DBs are somehow reflected in the CMDB, then
we can make the CMDB identities part of the handshake protocol. >>
I'm not sure that MDs and DBs are something
that will ultimately reside in a CMDB--maybe, but not necessarily.  
What I do agree on is that these things have identity and a lifecycle--that
they are, in short, resources.  What we need to understand is the
"capability" of a management domain.  This includes the
operations that form the API, its properties, and any events that it would
emit.  
Jimmy:  Has this information been
in the documents you've circulated to date?

<<Then
we can place the responsibility squarely in the MD’s lap (which it can
shovel off to the CMDB for sophisticated deployments) >>
There does seem to be general agreement
that a client is going to make a request to the management domain something
like: "Which data brokers do I use?".  I think we are all
agreeing on two things:
1. It's the management domain's job
to figure this out
2. How it does this is a point of variability
in the framework the implementation of which should be hidden behind an
interface.

<<Perhaps
there is always a default broker, and that is the one that is sent back
to the requestor, unless the MD accepts some parameter from the requestor,
that can influence the MD into giving the requestor back a non-default
broker.>>
I don't think we should make any assumptions
on a default broker or even IF there is a broker at all.  I think
it's perfectly valid for the management domain to return an empty set when
asked to provide the brokers to the client.

<<The
domain should be aware of these sorts of scoping information associated
with each broker and make it available on request.  Preferably the
client should be able to query for brokers by location or data type.  We
could let the query default to "my location" and "my product's
data" so clients that don't need to aggregate data from multiple brokers
would automatically find the broker that is most likely to be appropriate.>>
Here we are talking about the handshake
b/t the client and the management domain.  I'm thinking that the client
is also presented as a manageable resource so that we it would have a distinct
set of properties etc...  One of the things we could do at this point
is use metadata exchange to get this information.  This way, we can
just say that the decision on which broker(s) to provide is based upon,
among other things, the metadata provided by the client.  

<<I
think that we can keep it fairly simple >>
I agree.  

-mw



Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing
| (919) 543 0625 | weitzelm@xxxxxxxxxx

"Ebright, Don" <Don.Ebright@xxxxxxxxxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx

07/19/2007 10:48 AM

Please respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx>

To	"Cosmos Dev" <cosmos-dev@xxxxxxxxxxx>
cc
Subject	RE: [cosmos-dev] question on management domain and brokers

I think that we can keep it fairly
simple and perhaps even let most clients be unaware of the existance of
multiple data brokers.  
 
There are several reasons why
a customer might have multiple brokers, but in many cases the interests
of client software will split along the same boundaries.  For example,
a customer may install multiple independent products or suites with embedded
brokers.  Large customers will install multiple instances of a product
because of differing scopes of control such as regional data centers.
 
The domain should be aware of
these sorts of scoping information associated with each broker and make
it available on request.  Preferably the client should be able to
query for brokers by location or data type.  We could let the query
default to "my location" and "my product's data" so
clients that don't need to aggregate data from multiple brokers would automatically
find the broker that is most likely to be appropriate.
 
The scoping information for the
brokers could reside in the CMDB or it could just be part of the configuration
of the broker itself.
 
Regards,
 
Don

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hawkins, Joel
Sent: Thursday, July 19, 2007 9:04 AM
To: Cosmos Dev
Subject: RE: [cosmos-dev] question on management domain and brokers

Hmmm. Well, if we can assume
that the MD and the DBs are somehow reflected in the CMDB, then we can
make the CMDB identities part of the handshake protocol. Then we can place
the responsibility squarely in the MD’s lap (which it can shovel off to
the CMDB for sophisticated deployments) and well can get as wacky as we
like in the CMDB for modeling things like fail-over, etc. of our infrastructure.

That also means we can reuse
the sml editor (and whatever it becomes) as our configuration editor. GUI
jujitsu. ;-)
Cheers,
Joel

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Simmonds, Martin
Sent: Thursday, July 19, 2007 8:54 AM
To: Cosmos Dev
Subject: RE: [cosmos-dev] question on management domain and brokers
Joel,
I understood that there could be multiple DataBrokers(DB) too, and multiple ServiceBrokers. (SB)
For that to work, it has to be the function of the ManagementDomain(MD) to tell the requestor the name of the DatBroker(s) to use.  As yet, I don’t think it has been defined how that mechanism should work.  Does the MD make the decision as to what it tells the requestor, or does it give the requestor all the DataBrokers and let the Requestor decide?  I think it should be the MD, as it is after all, the Manager.   So How would the MD do this ?  Perhaps there is always a default broker, and that is the one that is sent back to the requestor, unless the MD accepts some parameter from the requestor, that can influence the MD into giving the requestor back a non-default broker.
Martin...
From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins, Joel
Sent: 19 July 2007 13:34
To: Cosmos Dev
Subject: RE: [cosmos-dev] question on management domain and brokers
Martin,
Does “the DataBroker” mean that DataBrokers follow the Highlander model (there can only be one)? I thought we were going to support multiple DataBrokers so that people could partition there monitoring infrastructure in some user-defined hierarchy (preferably one that was reflected in their CMDB).  
Cheers,
Joel

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev