On 10/25/2011 11:39 AM, Zane Bitter wrote:
Yes! I'm replying to myself.
On 24/10/11 19:03, Zane Bitter wrote:
> On 24/10/11 17:38, Russell Bryant wrote:
>> It seems like it'd be really hard to build up an abstraction on top of
>> agents we don't control.
>
> It sounds like this is the major unresolved question at the moment. I
> guess there are three basic options:
>
> 1) Limit mhsh functionality to org.mathariproject classes.
> 2) Document any requirements as a convention. Developers who follow the
> convention get mhsh support for free. Those who don't, don't.
> 3) Bake the necessary features into the agent library.
>
> The shell and agents are complementary, so in the interest of maximising
> the value of the Matahari ecosystem I think that option 1 is to be
> avoided if at all possible. If we get the shell right then I can easily
> imagine the majority of management being done through mhsh or its Python
> API rather than custom QMF consoles.
>
> It remains to be seen how feasible option 3 is. We could quite likely
> have some hybrid of options 2 and 3, however, where we specify a
> convention and provide the code to (optionally) implement that convention.
Here's an idea. We could export an extra object in each daemon with just
properties for the hostname and uuid. This would be done in the core
agent library code, so it is transparent to both internal and external
agents. When looking at a particular host, we could just look up all
matching objects of this type and get the agents associated with them.
Yeah, that seems like a good idea.
We could also install the schema.xml snippet for this built-in object.
All Matahari API users could xinclude it to ensure that they build in
the current version.
--
Russell Bryant