On 02/22/2011 10:11 PM, Perry Myers wrote:
>> Andrew/Adam: Random question, what links all of the top level
objects on
>> a single host together? Is there a common/shared UUID exposed by each
>> Agent? If a guest comes up and the Host agent appears, I can query that
>> Host object for UUID. But how do I know which Network Agent is the one
>> on the same guest as the Host Agent with the UUID that I just got?
> May be the agents on the host should have id that consists of Host-UUID
> and Agent-UUID concatenated?
> So if you pass the host ID into the image at the launch time all the
> agents would be able to use the composite IDs and the server side would
> be able to group agents by server without any specific lookups.
This sounds like a reasonable idea. First need to get an idea of how
Andrew/Adam implemented things already, but if there is no preexisting
solution then your idea seems good.
> You should probably use DNS discovery for the first pass just to make
> things simple and re-usable in future.
Yes, agreed. I meant to add to the list that perhaps we should:
* make the matahari init scripts check for a DNS SRV record for the
broker to connect to _iff_ the common matahari configuration file omits
the broker hostname/ip address. So this DNS SRV lookup would need to be
a common function included in the various matahari agent init scripts.
Question here is:
+ What about Windows? What tool do we use on Windows to do a DNS SRV
lookup?
+ Or maybe rather than making this an init script thing, we have the
agents do the lookup in code via a matahari common C function?
This would simplify the Windows stuff since we don't have init
scripts on Windows anyhow :) i.e. read conf file, conf file no haz
broker ip? No problems, check DNS SRV
+ What should the well known SRV name be? _matahari-broker or
something like that?
Perry
+
Windows has services. The services can start with particular priorities.
The services can depend on each other.
I do not know how you planned to implement Matahari on Windows but it
seems logical to have it as service.
You can have a very simple service that will do just one thing: fork a
child that will launch a shell and run python or ruby. The only
limitation is that you should assume that you do not have connection to
the desktop or terminal from the service and its children. If you need
it you have to write code to access it. At least this is what I remember
from my Windows times.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/