[virt-tools-list] virt-install and cloud-init, feedback wanted

[Christian Ehrhardt]

On Wed, Nov 20, 2019 at 11:48 PM Cole Robinson <crobinso at redhat.com> wrote:
>
> Hi all. The purpose of this mail is to get some feedback on pending
> cloud-init support in virt-install. If you're on the CC list here, I
> either pulled your email from a cloud-init discussion on the the
> virt-tools-list mailing list, or from the CC list of this virt-install bug:
>
> RFE: Provide cloud-init integration for VMs
> https://bugzilla.redhat.com/show_bug.cgi?id=981693
>
> For GSOC 2019 Athina Plaskasoviti completed some cloud-init integration
> work in virt-install. You can read her wrap up here:
> https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/
>
> Right now the code is sitting in a virt-manager.git branch, not yet
> pushed to master:
> https://github.com/virt-manager/virt-manager/tree/cloudinit
>
> I'll summarize the current behavior, and then ask some questions.
>

Thank you Cole for bringing this up,
FYI I have sent a link to this discussion to the cloud-init mailing
list [1] to let them have a word as well.

[1]: https://lists.launchpad.net/cloud-init/

> The branch adds a new 'virt-install --cloud-init' argument with several
> sub options. When specified, virt-install generates an empty meta-data
> file, a user-data file with the requested changes, stuffs them both into
> a cidata iso, which is used for the first VM boot and then deleted.
>
> This behavior is only triggered when --cloud-init is specified in some
> form, there's no automagic invocation of this support.
>
> The command sub options are:
>
> $ ./virt-install --cloud-init=help
> --cloud-init options:
>   disable
>   root-password-file
>   root-password-generate
>   ssh-key
>   user-data
>
> Their behavior:
>
> * disable=yes: boolean option to disable cloud-init in the VM for
> subsequent boots. Adds this block to user-data:
>   runcmd:
>   - [ sudo, touch, /etc/cloud/cloud-init.disabled ]
>
> * root-password-file=/MY/PATH: set the desired root password from the
> content of /MY/PATH on the host
>
> * root-password-generate=yes: boolean option, generate a random root
> password, set it in user-data, print it to the host text console and
> pause for a bit for the user to see and copy it. sorta inspired by
> virt-builder
>
> * ssh-key=/MY/KEY.pub: inject the ssh key from /MY/KEY.pub on the host
> into the cloud-init user-data

That seems fine to me, but without a path given should use the common
public key path like ~/.ssh/id_rsa.pub as a default.
Maybe it does already but you didn't mention - I haven't checked the code.

Looking at other use cases with cloud-init that I see, ssh-import-id
[2] is rather useful and common.
So you might consider adding some logic for that to the ssh-key option
(or another option)

[2]: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#ssh-import-id

> * user-data=/PATH/TO/user-data: ignore all other options and copy this
> file to the .iso as user-data
>
> When bare '--cloud-init' is specified, we default to generating a random
> root password and disabling cloud-init for subsequent boots:
> --cloud-init root-password-generate=yes,disable=yes
>
> We've explicitly rejected something like root-password=MY-PASSWORD
> because of the security implications of encouraging a password to end up
> in command line history. We've already had a CVE for something similar
> in virt-install.
>
> Also, I don't want virt-install to be in the business of specifying
> every cloud-init option under the sun, there's gotta be a better tool
> for that already. So I'd like to keep --cloud-init suboptions
> specifically targeted to expected virt use cases, and anything else can
> be served with custom user-data=

I like the ability to provide custom data, as it allows to use new
features without virt-* tools requiring an update.
And people today doing this in three steps can just cut out the middle
one as it is done by virt-inst then:

1. generate user data
2. generate ISO from user data (no more needed with the change)
3. pass that ISO to virt-inst


> One more point: my main interaction with cloud-init has historically
> been by grabbing a Fedora/RHEL cloud image, passing it to
> virt-install/virt-manager, and watching the boot hang, because there's
> no data provider and cloud-init times out talking to the network, and
> then I can't log in. I expect many people have hit this issue before.
> I've always worked around this by using 'virt-customize' to disable
> cloud-init and reset the root password. That's about the extent of my
> usage here, which is broadly why the bare `--cloud-init` is the way it was.

Talking about common use cases - I mostly use it to customize logins
as most of us.
But often enough I use features like the apt install to have some of
my tests automatically deploy or even start
1. deploy ubuntu cloud image
2. customize the login configuration
3. maybe install some applications
4. maybe run some commands automatically

A great example that makes use of that are the self-tests of curtin [3].
OTOH this would work with the custom user data option - I'm not sure
you'd want/need command line options for this.

[3]: https://git.launchpad.net/curtin/tree/tests/vmtests

> I'm also thinking to the future, if one day virt-install can detect that
> it was passed a distro cloud-init image, perhaps we can invoke some
> default behavior that gives the user a better chance of this config
> being usable out of the box. I figure that will match whatever we choose
> for the bare '--cloud-init' behavior

>From my usage my default expectation for bare --cloud-init would be to
behave like having --ssh-key set without a path using the default pub
key to be imported (see above for the suggestion).


> So, my questions are:
>
> * What are the usecases you see for virt-install cloud-init support?
> * Does the above meet your expectations?
> * Are we missing anything vital?
> * Do you have an opinion of what behavior bare '--cloud-init' should give?
> * Any other ideas, thoughts, feedback?
>
>
> Thanks,
> Cole
>


--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd