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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
