cmiN's profile - activity

Yes, the thing is that depending on the MSI installer architecture, the cloudbase subkey will be under the Wow6432Node (x86 installer on x64 system) or directly in the SOFTWARE key (x64 installer on x64 system). In the same way, you can find the installation directory in Program Files[ (x86)].

Hi!

If I'm getting right, you are trying to execute Sysprep before (and without Cloudbase-Init) and prepare your image for collection (and future instances based on it), then on some particular cases only (clouds) you want to install and full-execute Cloudbase-Init service. For doing this, without extra configuration, you can remove the specialize part from the xml and do the sysprep phase, then you can install cloudbase-init service and run it from services or execute it "at hand" using cloudbase-init.exe and cloudbase-init.conf files.

Anyway, what problems did you encounter along the road?

Thanks, also, the log seems very "healthy". About the network thing, yes, you could read more about this here (pre-networking): http://cloudbase-init.readthedocs.org/en/latest/plugins.html#clock-synchronization-pre-networking

Understood, that line was working with the old parsing method, but now everything has changed (in both stable and continuous versions) so there is no need to worry about that. Regarding Cloudbase-Init MSI versions, you should try with the continous one (beta) and if something goes wrong, the stable.

Hello salacryl,

I've been looking through the log and identified the issue (next time please post the entire log within a paste service). The problem is that you're using an outdated version of Cloudbase-Init which comes by default with the image you downloaded (may/june 2014) but since then, both the network config content in OpenStack and the parsing process have changed, so the old parsing method isn't able to process the different formatted content (which contains now as an additional field the hardware address value). I suggest you to install an updated version of Cloudbase-Init from here (http://www.cloudbase.it/cloud-init-wi...) and in the meantime we will try to find a way to keep the images updated.

Regarding the "new line for python 2.7.3", I'm not sure what are you talking about, could you post a link to that article/information? But as far as I know, the issue explained above isn't related to such trick.

Hello kaizersose,

For future posts with long traces/logs, please use a paste service like sprunge.us, pastebin.com or paste.openstack.org to make the log parsing more easier. As you can see in the logs, you're using in the instance a configuration ISO drive as metadata provider and the service was unable to extract it correctly through the bsdtar utility (and that's why the userdata plugins won't reach your script content), so maybe something it's scrambled in your installation or you don't have the appropiate MSI installer with the used architecture.

Please provide more details about the windows instance type/version you're using and also try with one of the continuous (beta) installers that suits you best: http://www.cloudbase.it/cloud-init-wi...

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 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).

Now you can read it online: http://cloudbase-init.readthedocs.org/en/latest/index.html#

Hello again, Search for these return codes and #ps1_... markers through the documentation (http://cloudbase-init.readthedocs.org/en/latest/index.html#) to find more info.

Hello,

We are doing many tests on WS2012 R2 (W8 X64) and we couldn't observe such behavior (on VMWare and on OpenStack (with devstack)). If the DHCP is disabled (through the custom IP and broadcast addresses which are set first), then there should be no problem for "ready" state of the NIC when setting DNSes. Also, there is no default validation (ping/request) for the custom addresses (only basic checks) from the OS API when setting them, so you don't have to worry if that DNS address is valid and reachable in that particular moment.

One solution for the moment is to:

1. Provide additional and extensive information regarding the environment you are currently using for your windows image and a full cloudbase-init log. (infrastructure, type of deployment, versions, configuration files, metadata content etc.)

2. Make some tests until the error is reproduced using the beta installer found here: https://www.cloudbase.it/downloads/Cl... with this patch applied: https://review.openstack.org/#/c/219305/ if it's not present there yet (because it may take a little time for the merge and the lastest build) and you should see in the logs the error code for which the DNS setting has failed.

Hello again rynnoworld, A patch for solving this out has been merged. Like ader1990 said, your script has to return an exit code as 1000 + <2 bits> where the first one (LSB) is the reboot bit and the second one is for taking care of plugin reexecution. Batch example: http://sprunge.us/HEAB?bat

Hi adamski,

Here is an in-development documentation which we are working on: https://review.openstack.org/#/c/188903/ It will be available on readthedocs soon enough, until then, if you want to read it in html form, you can clone the repo from stackforge git and apply the patch or clone the project directly from my repo: https://github.com/cmin764/cloudbase-..., then switch to "doc" branch and after that, run "make html" under the "doc" directory; open your "build/html/index.html" and you're good to go.

It's currently taking care of general aspects of cloudbase-init, but in the near future, there'll be available complete information about the different types of metadata and what is the meaning of every possible key/field. Anything more beyond that, is usually having to do with OpenStack specific use cases, but there will be a FAQ section as well for things like that.

Currently it supports doing that if and only if you supply the script in the user data (first line starting with #ps1_sysnative or #ps1_x86). It'll be available soon a feature for taking care of return codes in this way even when you're dealing with stand-alone scripts. Also, documentation regarding this will be available, just stay tuned for updates.

I'm working on it and it'll be available this night.

It may be for sure an issue with the python-windows bindings and load of the requested DLLs.

Are you sure that you're using the latest installer? Can you reproduce the slow behavior by doing as few steps as possible (like reboot, then load - or - uninstalling cloudbase-init, cleaning up the registry/disk remnants, then installing and running the service again)? If yes, then tell us how and/or try replacing for yourself the line above "return" with this:

import importlib
module = importlib.import_module(parts[0])

To see if the function itself is the problem, but there are many chances that a simple import like:

from cloudbaseinit.osutils.windows import WindowsUtils

will have the same result. What are the accurate details of your platform (like os name, edition, service pack etc.)?

Also, keep in mind that Microsoft's Windows 2003 support will end in 75 days and ours too, so we can't do too much, especially due to the fact that the installer was tested against Windows Server 2003 x86 SP2 both Enterprise and Standard editions and we couldn't find such noticeable slow situations.

Hi,

In short, the networkconfig plugin will take automatically the network info from metadata and will statically configure each interface inside the instance. But for this to happen, you must keep in mind two things: the DHCP on the subnet attached to the private network must be disabled and the flat network injection must be enabled. To enable flat injection, just add the entry "flat_injected=True" to /etc/nova/nova.conf under the DEFAULT group. To disable the DHCP, you can use the interface/dashboard to untick the DHCP checkbox by editing the subnet on the private network or you can simply use the --disable-dhcp option with the neutron subnet-update/create command.

What happens next: Nova will see that DHCP is disabled and injection is allowed, so will gather network information using the networking driver. This info is handled by virt (netutils) and used to fill in a debian-interfaces-like template which will be exposed as a metadata content pointed out by the metadata json key "network_config". The networkconfig plugin from cloudbase-init finds the key, then searches further for the "content_path", then reads the entire content from that path which is very similar to /etc/network/interfaces file from debian systems. For each available NIC in the instance, there's also an eth<n> entry and for each entry, there's a set of network details as address, netmask, gateway, broadcast, dns, mac etc. Finally, using these details, each corresponding network interface from the instance is configured statically.

For extra setting, you could use a powershell script passed as userdata, just to configure what you want as you want. The userdata could be provided from the interface when creating the instance by wizzard or with --user-data option under nova boot command. Don't forget to put as a first line the comment "#ps1" or "#ps1_x86" indicating that will follow a powershell script.

Hope this will answer your question(s) :).