Open Stack

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.