Open Stack

Excerpts from Joshua Harlow's message of 2013-12-06 23:53:47 -0800:
> Agreed,
> 
> Chatting earlier today on #cloud-init about all of this I think scott convinced me that maybe we (the joint we in the community at large) should think about asking ourselves what do we really want a guest agent for/to do?
> 
> If it's for software installation or user management then aren't puppet, chef, juju (lots of others) good enough?
> 

Right those are system management agents.

> If it's for tracking what a vm is doing, aren't there many existing tools for this already (sounds like monitoring to me).
>

Right general purpose system monitoring is a solved problem.

> Is there a good list of what people really want out of a guest agent (something unique that only a guest agent can do/is best at). If there is one and it was already posted, my fault (I am on my iPhone which is not best for emails...)
>

So what is needed is domain specific command execution and segregation
of capabilities.

With a general purpose config tool like chef or puppet, doing MySQL
backups or adding MySQL users isn't really what they do.

One might say that this is more like what fabric or mcollective do. That
is definitely closer to what is desired. However there is still a
different desire that may not fit well with those tools.

Those tools are meant to give administrators rights to things on the
box. But what Trove wants is to give the trove agent the ability to
add a given MySQL user, but not the ability to, for instance, read the
records and pass them back to the trove service.

Likewise, Hadoop needs to run hadoop jobs, but not have full SSH to
the machine. While the _nova_ admin with root on compute nodes may
have the ability to just peek in on VMs, there is value in keeping the
Trove/Savanna/Heat admins segregated from that.

So basically there is a need for structure that general purpose tools
may not have. I admit though, it seems like that would be something
other tools outside of OpenStack would want as well.