alicefr / kata-local-ci-setup Goto Github PK

In certain cases, the CI check doesn't fail if the jenkins_job.sh script fails.

In issue #8 I noticed a quoting problem, but the fix I proposed simply allows the script to run. It does not do the right thing. Notably, it ends up not executing the chown for the kata user correctly.

Here, I'd just like to check & suggest whether we need the parameters currently used.

We use, for now:

• --ram, I'd suggest using --memory instead, just because it was introduced in order to deprecate --ram;
• --vcpus`, that's ok;
• --disk, that's ok;
• --graphics vnc,listen=0.0.0.0, do we have to pass that? or can se just fallback to the console and happy about that?
• --os-type=$osvariant, similarly to the --ram / --memory case, we better use --os-variant here;
• --network network=default, why do we need this?

Last but not least, I wonder whether we could be opinionated and force people to use -c qemu:///system just to ensure we'll, later on, be able to ssh into the machine.

What do you think?

The kubernetes tests with cri-o on fedora 32 are failing
cc @fabiano

kata_ci_job.log

Quite similar to #1, I'd suggest using kata-$d as the VM name. Here we don't have to explicitly check for the name as virt-install would just stop in case there's already a VM with such name.

This script could be used for spawning several VMs in parallel, which would result in errors in case the disk is not set by the user.

Here, I'd recommend a few things:

1. Instead of kata.qcow2, use kata-$d.qcow2 by default, as this would already allow users to have different distros running in parallel;
2. Check whether $disk already exists in the system, just to avoid overwriting something without advertising the user;

Note, I thought about trying a pseudo smart approach of naming the image kata-$d, checking for the existence, and creating a kata-$d-nn instead. However, I sincerely think it's over-engineering the problem at this point and I'd be way happier with only 1 and 2 being implemented.

Fedora is using cgroup v2 to make this working with together we need to switch back to v1. Trying with fedora 33, I think the issue might have been solved.

cc @fidencio

Instead of hardcoding an ip address, or even requiring the user to know the VM's IP address, what about enforcing the usage (in the documentation) of the libvirt-nss?

Having this module installed in the host allows the user to simply ssh $vm_name.

When running ./virt-build-kata -d ubuntu -k <key> -o <volume> I get:

+ virt-builder ubuntu-18.04 [...] --firstboot-command 'chown kata:kata -R /home/kata' '' [...]
virt-builder: error: too many parameters, expecting ‘os-version’

If reporting bugs, run virt-builder with debugging enabled and include the 
complete output:

  virt-builder -v -x [...]

Notice the misquoted ''.

I'm running into a problem. The VM creation

virt-build-kata -d ubuntu -k <...> -o kata-ci-ubuntu.qcow2

goes well but then ansible fails pretty much immediately with

fatal: [192.168.122.249]: UNREACHABLE! => {"changed": false, "msg": "Failed to create temporary directory.In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\", for more error information use -vvv. Failed command was: ( umask 77 && mkdir -p \" echo /home/kata/.ansible/tmp \"&& mkdir \" echo /home/kata/.ansible/tmp/ansible-tmp-1621497642.2791765-263890-25594791683090 \" && echo ansible-tmp-1621497642.2791765-263890-25594791683090=\" echo /home/kata/.ansible/tmp/ansible-tmp-1621497642.2791765-263890-25594791683090 \" ), exited with result 1", "unreachable": true}

Creating the VM, I requested Ubuntu and ended up with 18.04.5. I have changed the VM IP addresss in hosts.yaml to match my actual VM but otherwise I believe I'm following the instructions. @alicefr Any ideas what I'm doing wrong? (Sorry if it's something obvious - this is my first time with ansible...)