[openstack-dev] Unified Guest Agent proposal
harlowja at yahoo-inc.com
Sat Dec 7 07:53:47 UTC 2013
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?
If it's for tracking what a vm is doing, aren't there many existing tools for this already (sounds like monitoring to me).
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...)
Sent from my really tiny device...
> On Dec 6, 2013, at 11:37 PM, "Clint Byrum" <clint at fewbar.com> wrote:
> Excerpts from Joshua Harlow's message of 2013-12-06 12:27:10 -0800:
>> Another idea that I'll put up for consideration (since I work with the
>> cloud-init codebase also).
>> Cloud-init which currently does lots of little useful initialization
>> types of activities (similar to the racker agents activities) has been
>> going through some of the same questions as to should it be an agent
>> (or respond to some type of system signal on certain activities, like new
>> network metadata available). So this could be another way to go.
>> Including (ccing) scott who probably has more ideas around this to :-)
>>  https://launchpad.net/cloud-init
>>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626
> I have a theory that cloud-init is so popular and useful precisely
> becuase it does _not_ expand into ongoing-management territory. It is
> really amazing at "setting the table" for instances when you choose
> not to do image based software deployment. Even if you do image based
> deployment, it is really great for abstracting away all the cloud details
> and customizing an instance.
> The problem with conflating those two tasks is that early boot
> configuration carries quite a different set of constraints and assumptions
> when compared to what an agent will be tasked with.
> I would be interested in seeing the cloud-config piece pulled out into
> its own library. That syntax is pretty popular, and in fact was mostly
> mimicked by the cloudformation tool 'cfn-init'. I suspect that they did
> not just do this work in cloud-init because it is GPLv3, or because of the
> Canonical CLA.. two things that scare off IP-hungry companies like Amazon.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev