Bug #1040245 proposes adding support for image based provisioning in OpenStack. This is a potentially simpler nearer term proposal that doesn't try to tackle full image based provisioning for regular recipes (which depends on an Image Library, etc, as well as getting various things related to kickstart files working properly). Instead this proposal is to add a *new* experimental virt installation task to provide it for *guest* recipes based on an explicit image URL, and using the "NoCloud" provider to pass data to cloud-init: http://cloudinit.readthedocs.org/en/latest/topics/datasources.html#no-cloud Here's a general outline of the approach: http://spinningmatt.wordpress.com/2014/01/08/a-recipe-for-starting-cloud-images-with-virt-install/ As with the experimental OpenStack approach, this task *may not* initially offer all of the niceties offered by /distribution/virt/install and /distribution/virt/start. Providing a direct URL to the image also means it will often need to be paired with lab controller restrictions if the image URL isn't backed by an appropriate CDN. This should help lay a solid foundation for bug #1040245
Via cloudbase-init, this may even allow for Windows images as guests (although you couldn't actually run tasks there): http://www.cloudbase.it/cloud-init-for-windows-instances/
Created attachment 937796 [details] a diff file for run-test.sh between orginal virt-install task and new cloud-init task
Created attachment 937797 [details] a script to translate kickstart file to cloud-init user-data
Docs: http://gerrit.beaker-project.org/3355
Docs are here: https://beaker-project.org/docs-develop/user-guide/beaker-provided-tasks.html#distribution-virt-image-install Suggested test case: 1. Create a job with a guest recipe containing /distribution/install,/distribution/reservesys. In the guest recipe, use Fedora 20. 2. In the host recipe, have the following tasks: /distribution/install /distribution/virt/image-install CLOUD_IMAGE=http://download.fedoraproject.org/pub/fedora/linux/updates/20/Images/x86_64/Fedora-x86_64-20-20140407-sda.qcow2 /distribution/virt/start Expected results: Guest recipe successfully runs. After reservesys is reached, you can log in to the guest recipe using your SSH key.
I uploaded /distribution/virt/image-install 1.0-2 which fixes a mistake in the Makefile, which was causing get_user_data.py to be omitted from the RPM. ./runtest.sh: line 972: ./get_user_data.py: No such file or directory
/distribution/virt/image-install 1.0-3 adds the requirement on pykickstart which I originally missed.
I have tested with /distribution/virt/image-install 1.0-3, and found I can installed guest successfully, but I can only login ths guest with ssh keys, if I don't set my ssh keys, I can not login the guest.
(In reply to xuezhi ma from comment #10) > I have tested with /distribution/virt/image-install 1.0-3, and found I can > installed guest successfully, but I can only login ths guest with ssh keys, > if I don't set my ssh keys, I can not login the guest. I think that this is a property of the Fedora cloud image. I think the user is fedora and password is fedora and the "root" a/c is locked/disabled.
Right, that is the expected behaviour of the F20 cloud image. The root account is not locked, and you can log in as root using your Beaker public SSH keys, because we update /root/.ssh/authorized_keys. But sshd is configured not to accept passwords in the cloud image. For now we aren't planning to work around or hide those differences in /distribution/virt/image-install.
Beaker 19.0 has been released.