Bug 1108455 - [RFE] Task for direct URL image based provisioning of guest recipes
Summary: [RFE] Task for direct URL image based provisioning of guest recipes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Community
Component: tests
Version: develop
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: 19.0
Assignee: matt jia
QA Contact: Amit Saha
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-12 05:20 UTC by Nick Coghlan
Modified: 2018-02-06 00:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-25 07:18:34 UTC


Attachments (Terms of Use)
a diff file for run-test.sh between orginal virt-install task and new cloud-init task (8.38 KB, text/plain)
2014-09-16 05:55 UTC, matt jia
no flags Details
a script to translate kickstart file to cloud-init user-data (2.53 KB, text/plain)
2014-09-16 05:56 UTC, matt jia
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.