Open Stack

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?

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[1] 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[2] 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 :-)
>> 
>> [1] https://launchpad.net/cloud-init
>> [2] 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev