Hi On Thu, Jul 10, 2014 at 8:15 PM, Boris Parak <[email protected]> wrote: >> It makes total sense and I would love to just rely in cloud-init. The >> problem is that I had no luck making it work in all distributions, for >> example Ubuntu 12.04. > > Was it the network configuration issue you are mentioning below or > something else?
Yes, the problem is the network. >> [..] >> Another problem is adding new features to it as it may take time to >> put them in the upstream repo. This may be fixed having a special > > I would go with the second option. Advanced configuration shouldn't be > handled by could-init directly anyway. That's where chef or puppet > come in. Network, basic access (ssh keys, user accounts), maybe some > dynamic mounts or packages installed from repos ... that's as far as I > would go with cloud-init. Configuring complex applications without > provisioning/orchestration is not a good idea. I think it would be nice to have the same semantics in both. For example the execute scripts from the context functionality. It can also be done using the USER_DATA feature of cloud-init but it would be better to do the same using FILES_DS and INIT_SCRIPTS. >> If there's a way to make it work reliabily without dhcp and there's a >> nice way to add new features without changing cloud-init I will push >> for it and deprecate the context packages. > > Is static network configuration really that popular? I had no idea ... > Ok, I will do what I can to find a solution. As for the second part, > do you have an example of such a feature? Yes, there are a lot of people that uses static network configuration: * The dhcp server needs to be in the same networks which is serving. With many private and dynamic networks this is cumbersome. * In some datacenters the use of dhcp is strictly forbidden. We had this problem in some companies. * This many not be a real reason but having one less daemon makes the system easier to deploy. I've been working on the cloud-init scripts this weekend (mainly testing with CentOS 7) to make the network configuration compatible with "ip" and the new interface names but it's still having problems. I may have to ask for help with that. As for examples for features that we could add I cannot think of anything now. It's usually a feature added to OpenNebula that needs some action in the guest system. I suppose all can be done with scripts added to the context CD and executed by cloud-init. Cheers -- Javier Fontán Muiños Developer OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | @OpenNebula | github.com/jfontan _______________________________________________ Dev mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/dev-opennebula.org
