Implementing AutoYaST support

[dmacvicar]

Motivation

We are using the provider internally heavily to test non-released products, and this means sometimes installing the machine from scratch and no images are available.

https://hackweek.suse.com/16/projects/implement-kernel-cmdline-and-slash-or-autoyast-slash-kickstart-support-in-terraform-provider-libvirt

Approach

• While passing the profile via fw_config would be awesome, it is not supported. Parallel efforts will be done to move into that direction.
• The approach will likely be a ISO image containing /autoinst.xml using autoyast=device://
• Some code may be shared with cloud-init support code
• I believe (without much evidence) the Ignition code can be simplified, and there is no need to upload the profile to a volume. In that case, a fw_config based version could be generic for both AutoYaST and Ignition. volume is needed to have fw_config file= local to the libvirt daemon vs terraform.

Task List

• [ ] Refactor cloud-init code to make it generic (ISO with X content + kernel option)
• [ ] Implement AutoYaST
• [ ] Implement unit tests
• [ ] Look if integration tests make sense

[MalloZup]

@dmacvicar i am not sure that this feature could make sense in the direction we are going and we are now.

For me an user should be able to build the qcow image before using it.

For example, an user need to use kiwi for building their qcow ( this is equivalent of using autoyast on the highlevel). Or an user can use packer or other tools for building images a he wish.

Additionally we have also cloud-init for post refinement.

Mixing and adding autoyast/kickstart etc can also add more complexity errors and maintainance on provider.

I would vote to close it because from the user perspective is not needed ( and also the codebase would be incosistent) it is not needed on the libvirt level.

And it doesn't add a new functionality/feature that an user can have using other tools. We are offering another way of solving a problem that it might be solved easy with external tools and not coding/maintainance efforts from our side. ( this is my main motivation).

Also i am keeping count of our current status of ressources/bugs/issue and "focus" level which might need to focus for future.

I think in this context autoyast doesn't add really a value on the libvirt-terraform ( we are mixing provisioning , deploy and image building phases which is imho not good).

[dmacvicar]

I think this would be a great addition for SUSE internally, as we deal a lot with testing installations. However, I understand nobody is wants to work on it now.

[MalloZup]

I reopen this one because after thinking and your last comment is valid. So we might add it.

[MalloZup]

@dmacvicar i would be happy to continue this feature and finish it. ( after some discussion i think this still relevant for SUSE/openSUSE). ( we might also add open doors for Kickstart etc, but let see)

Would be helpful if you can share the status of what is missing to make it working, and if the actual status is reflecting the card. ( missing code, features etc).

We can sync on irc or github which medium you wish

[dmacvicar]

You should read the link https://hackweek.suse.com/16/projects/implement-kernel-cmdline-and-slash-or-autoyast-slash-kickstart-support-in-terraform-provider-libvirt , as it has most of the information.

Some parts are there, like the kernel and initrd options, which allow you to create volumes based on those to boot. Originally, I wanted to use _fwcfg (even did a PR to linuxrc) to pass the autoyast profile directly via qemu, but then realized I still needed to have it local to the hypervisor, so I still needed a volume, so that feature only saved me from creating a ISO or drive with /autoyast.xml.

So not sure how to proceed. Either the user creates the kernel and initrd volumes, and we add support for autoyast in a very similar fashion to cloudinit_disk (an iso with /autoyast.xml), or we have the autoyast resource also manage the initrd and kernel.

Then there is the problem of the design (the reboot loop part). For something declarative, the installation should not run after the domain is created, but as part of creation, so that once it is installed, we don't install again. That would add some complexity, but then we could start the domain with the options, change it, and just then have the domain as "created". It would need some thinking how to detect that the OS is installed, just like we do with the ip address. Ideas?

[MalloZup]

@dmacvicar ok thx for feedback.

Something radical different:

I think we could "solve the problem at devops level", implementing a kiwi provider that generate qcow. ( same idea could be for packer provider.)

In this way we can have everything managed on the terraform level.

The current existing workaround for testing ISO ( i just to use packer + autoyast or kiwi + autoyast from ISO).

About the current autoyast/installer support direction: I did previously a test by passing the kernel_cmdline option and also withou the autoyast resource as user i was fine.

The main issue here is the fact we keep reinstalling in a loop. ( but this is somehow hackward from libvirt perspective.. i mean libvirt in this doesn|t make someone the life easy :smile.).

yop i think in theory what you write is true, but to detect that a OS ( different distro etc) is installed, looks really complex especially in a stable way .. :smile: But indeed i think is because of the following issue https://serverfault.com/questions/740694/how-to-set-kvm-kernel-boot-only-once the only way we could implement it.. ( if we decide/find out a good implementation of the autoyast way)

[MalloZup]

@dmacvicar https://libvirt.org/formatdomain.html#elementsEvents thx lot to cedric for this. I think this could solve the issue

[dmacvicar]

How would overriding these actions help? We would still need to remove the kernel/initrd/profile from the command line.

I was thinking among the same lines as the qemu-agent connection callbacks that I found for the ip discovery. In that case we would loop until the callback agent-connected comes. We could as well wait for the reboot callback.

May be we could implement this as a hook into the domain creation using callbacks:

• setups the kernel/autoyast profile
• then at the end hook for waiting for a reboot using the event callbacks
• then detect if the OS was installed if possible (eg. using virt-cat/guestfs & friends, and then ending the domain creation as successful.
• then remove the kernel/autoyast profile from the domain definition
• then domain creation resource finishes successful

[MalloZup]

yop i was thinking in the same direction ( i didn't explain the implicit part.. :smile: )

I agree with procedure, the only tricky part is the OS-detection installation ( we might just skip it)

But i think this could be already a valid case-study for a possible working implementation which is not super-complex.

[MalloZup]

This is fixed by pr waiting review