OpenNebula

The scripts are changed so they are only run when it's called with "start". There's still the problem of when the scripts are called.

When these packages were firstly created I thought that it was better to let all the services start and then do the changes but I am probably incorrect. Do you have an idea where it should be started? I want the packages to behave as close as possible in all the distros.

We are going to move these packages to an external repo in a near future so it's easier to contribute to them.

My working setup is:

http://grid5.mif.vu.lt/mif/debian6/debootstrap.sh
http://grid5.mif.vu.lt/mif/debian7/debootstrap.sh
http://grid5.mif.vu.lt/mif/ubuntu1204/debootstrap.sh
http://grid5.mif.vu.lt/mif/centos5/bootstrap.sh
http://grid5.mif.vu.lt/mif/centos6/bootstrap.sh

Main idea is to let run vmcontext as early as possible before networking.
That allows to reuse the same image for different VM without temporary IP conflicts.

One of the things that the context packages do is to delete the network configuration so in the next boot it does not get configured. With this there should be no problem with a VM getting a temporary IP before being configured by context.

Do you have a list of services that should be up before vmcontext?

My experience is that on different Linux distributions networking is started in different ways. For e.g. Debian/Ubuntu starts it in single user mode, when CentOS - in multi user mode.

At least my config works for Debian by using "# X-Start-Before: networking" and "# Default-Start: S". For Ubuntu I use upstart task http://grid5.mif.vu.lt/mif/ubuntu1204/vmcontext.conf - not ideal, but working for the moment - I didn't find reliable way to create upstart task with condition to start before network devices are configured (we can look into cloud-init for that).

Additionally I implement EC2_USER_DATA - I put it into /etc/rc.local or configure to run from /etc/rc.local, but even here we have to be careful - because network could not be yet up really.