Bug 1108455

Summary: [RFE] Task for direct URL image based provisioning of guest recipes
Product: [Retired] Beaker Reporter: Nick Coghlan <ncoghlan>
Component: testsAssignee: matt jia <mjia>
Status: CLOSED CURRENTRELEASE QA Contact: Amit Saha <asaha>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: developCC: aigao, asaha, dcallagh, ebaak, jzhao, mjia, rmancy
Target Milestone: 19.0Keywords: FutureFeature, Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-25 07:18:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
a diff file for run-test.sh between orginal virt-install task and new cloud-init task
none
a script to translate kickstart file to cloud-init user-data none

Description Nick Coghlan 2014-06-12 05:20:19 UTC 
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
Comment 1 Nick Coghlan 2014-06-12 05:23:14 UTC 
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/
Comment 2 matt jia 2014-09-16 05:55:31 UTC 
Created attachment 937796 [details]
a diff file for run-test.sh between orginal virt-install task and new cloud-init task
Comment 3 matt jia 2014-09-16 05:56:20 UTC 
Created attachment 937797 [details]
a script to translate kickstart file to cloud-init user-data
Comment 4 Dan Callaghan 2014-09-26 06:49:19 UTC 
Docs: http://gerrit.beaker-project.org/3355
Comment 6 Dan Callaghan 2014-09-26 07:35:14 UTC 
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.
Comment 8 Dan Callaghan 2014-09-29 03:18:58 UTC 
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
Comment 9 Dan Callaghan 2014-09-29 05:11:43 UTC 
/distribution/virt/image-install 1.0-3 adds the requirement on pykickstart which I originally missed.
Comment 10 xuezhi ma 2014-09-30 09:18:26 UTC 
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.
Comment 11 Amit Saha 2014-09-30 11:07:27 UTC 
(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.
Comment 12 Dan Callaghan 2014-10-01 00:32:22 UTC 
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.
Comment 14 Dan Callaghan 2014-11-25 07:18:34 UTC 
Beaker 19.0 has been released.