Revision history [back]

Tested with 0.9.9.dev29 (beta) x64 on ws2008 and ws2012 (but it's working in the same manner with other versions/architectures) and the default behavior is the following:

Cloudbase-Init is installed and the image is sysprepared, which implies running the service with the unattend configuration file which will not allow it to reboot the computer or stop by itself and the only plugins that will be executed are the one responsible for MTU and the one that sets the host name. Also, the default metadata providers search order is configuration drive, then the http, so for sure it will use the drive (if available in the system). So, it's absolutely normal that the last two lines in the unattend log file to be the setting host name and the deleting metadata temporary folder, because it will not stop nor executing something other else until the computer is rebooted (by a special script that uses sysprep or manually by the user). After reboot, the service will execute normally (cloudbase-init.conf) and will iterate through all the plugins (inclusive the one that sets the password) and it takes the password found in the metadata (through the http service) and it updates it accordingly (using nova get-password with the used private key, shows the custom password).

As far as I know, the config image isn't unmounted automatically by the system or the service, so it'll be present at each boot. In short:

1. Under a default devstack OpenStack deployment, the attached configuration drive and the http providers will be available until manual unmounting.
2. With sysprep/unattend/first run, only the MTU and host name plugins will be executed.
3. The password plugin (among others) will be executed within the first normal boot (if other plugins didn't request a reboot already).

Tested with 0.9.9.dev29 (beta) x64 on ws2008 and ws2012 (but it's working in the same manner with other versions/architectures) and the default behavior is the following:

Cloudbase-Init is installed and the image is sysprepared, which implies running the service with the unattend configuration file which will not allow it to reboot the computer or stop by itself and the only plugins that will be executed are the one responsible for MTU and the one that sets the host name. Also, the default metadata providers search order is configuration drive, then the http, so for sure it will use the drive (if available in the system). So, it's absolutely normal that the last two lines in the unattend log file to be the setting host name and the deleting metadata temporary folder, because it will not stop nor executing execute something other else until the computer is rebooted (by a special script that uses sysprep or manually by the user). After reboot, the service will execute normally (cloudbase-init.conf) and will iterate through all the plugins (inclusive the one that sets the password) and it takes the password found in the metadata (through the http service) and it updates it accordingly (using nova get-password with the used private key, shows the custom password).

As far as I know, the config image isn't unmounted automatically by the system or the service, so it'll be present at each boot. In short:

1. Under a default devstack OpenStack deployment, the attached configuration drive and the http providers will be available until manual unmounting.
2. With sysprep/unattend/first run, only the MTU and host name plugins will be executed.
3. The password plugin (among others) will be executed within the first normal boot (if other plugins didn't request a reboot already).