diff --git a/.gitignore b/.gitignore index 706ef3fca..4aa0869f8 100644 --- a/.gitignore +++ b/.gitignore @@ -31,10 +31,6 @@ scripts/workflows/fstests/lib/__pycache__/ scripts/workflows/blktests/lib/__pycache__/ scripts/workflows/lib/__pycache__/ -vagrant/kdevops_nodes.yaml -vagrant/.Vagrantfile.generated -vagrant/Vagrantfile -.vagrant/ include/ @@ -97,6 +93,6 @@ workflows/linux/refs/user scripts/kconfig/.nconf-cfg .dynamic-kconfig.* -vagrant/Kconfig.passthrough_libvirt.generated +kconfigs/Kconfig.passthrough_libvirt.generated archive/ diff --git a/Makefile b/Makefile index c6a5c321f..1173697c4 100644 --- a/Makefile +++ b/Makefile @@ -17,7 +17,6 @@ export KDEVOPS_EXTRA_VARS ?= extra_vars.yaml export KDEVOPS_PLAYBOOKS_DIR := playbooks export KDEVOPS_HOSTFILE ?= hosts export KDEVOPS_NODES := -export KDEVOPS_VAGRANT := export PYTHONUNBUFFERED=1 export TOPDIR=./ export TOPDIR_PATH = $(shell readlink -f $(TOPDIR)) @@ -129,9 +128,6 @@ ifneq (,$(ANSIBLE_EXTRA_ARGS)) DEFAULT_DEPS += $(KDEVOPS_EXTRA_VARS) endif -ifeq (y,$(CONFIG_VAGRANT)) -DEFAULT_DEPS += $(KDEVOPS_VAGRANT) -endif DEFAULT_DEPS += $(DEFAULT_DEPS_REQS_EXTRA_VARS) @@ -230,7 +226,7 @@ $(KDEVOPS_HOSTS): .config ansible.cfg $(KDEVOPS_HOSTS_TEMPLATE) --extra-vars=@./extra_vars.yaml DEFAULT_DEPS += $(KDEVOPS_NODES) -$(KDEVOPS_NODES) $(KDEVOPS_VAGRANT): .config ansible.cfg $(KDEVOPS_NODES_TEMPLATE) +$(KDEVOPS_NODES): .config ansible.cfg $(KDEVOPS_NODES_TEMPLATE) $(Q)ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ --inventory localhost, \ $(KDEVOPS_PLAYBOOKS_DIR)/gen_nodes.yml \ diff --git a/Makefile.kdevops b/Makefile.kdevops index 60d79a5a3..d9c840d0b 100644 --- a/Makefile.kdevops +++ b/Makefile.kdevops @@ -25,19 +25,6 @@ kdevops_configure_libvirt: $(KDEVOPS_PLAYBOOKS_DIR)/libvirt_user.yml -e "skip_install=True" \ -e 'running_user=$(USER)' -kdevops_vagrant_deps: \ - kdevops_install_libvirt \ - kdevops_configure_libvirt - -PHONY += kdevops_vagrant_deps -KDEVOPS_VAGRANT_WORK := kdevops_vagrant_deps - -kdevops_vagrant_boxes: - $(Q)ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ - --inventory localhost, \ - $(KDEVOPS_PLAYBOOKS_DIR)/install_vagrant_boxes.yml -PHONY += kdevops_vagrant_boxes -KDEVOPS_VAGRANT_WORK += kdevops_vagrant_boxes kdevops_verify_libvirt_user: $(Q)ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ @@ -45,7 +32,6 @@ kdevops_verify_libvirt_user: $(KDEVOPS_PLAYBOOKS_DIR)/libvirt_user.yml -e "only_verify_user=True" PHONY += kdevops_verify_libvirt_user -KDEVOPS_VAGRANT_WORK += kdevops_verify_libvirt_user kdevops_libvirt_storage_pool_create: $(Q)ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ @@ -53,9 +39,7 @@ kdevops_libvirt_storage_pool_create: $(KDEVOPS_PLAYBOOKS_DIR)/libvirt_storage_pool_create.yml PHONY += kdevops_libvirt_storage_pool_create -KDEVOPS_VAGRANT_WORK += kdevops_libvirt_storage_pool_create -kdevops_deps: kdevops_terraform_deps $(KDEVOPS_VAGRANT_WORK) $(KDEVOPS_DEPS) @echo Installed dependencies PHONY += kdevops_deps diff --git a/README.md b/README.md index 4d9be800c..5c602d756 100644 --- a/README.md +++ b/README.md @@ -40,10 +40,9 @@ an entire lab for Linux kernel testing for a complex subsystem in a jiffy. It makes use of local ansible roles and optionally lets you use [libguestfs](https://libguestfs.org/) with libvirt or terraform in order -to support an cloud provider. Support for vagrant in kdevops exists but is now -deprecated in favor of [libguestfs](https://libguestfs.org/) since vagrant -lacks any active maintenance, new development should use and focus on -[libguestfs](https://libguestfs.org/). +to support a cloud provider. Historical support for Vagrant has been +removed in favor of [libguestfs](https://libguestfs.org/), which is +actively maintained. Variability is provided through the same variability language used in the Linux kernel, kconfig. It is written by Linux kernel developers, for Linux kernel @@ -334,10 +333,8 @@ Below are sections which get into technical details of how kdevops works. * [How is extra_vars.yaml generated](docs/how-extra-vars-generated.md) * [How is the ansible hosts file generated](docs/the-gen-hosts-ansible-role.md) * [What are and how to generate the kdevops nodes files](docs/the-gen-nodes-ansible-role.md) - * [How is the dynamic Vagrant files generated](docs/the-gen-nodes-ansible-role-vagrant.md) * [How is the terraform kdevops_nodes variable generated](docs/the-gen-nodes-ansible-role-terraform.md) * [How are the terraform terraform/terraform.tfvars variables generated](docs/the-terraform-gen-tfvar-ansible-role.md) - * [Why Vagrant (deprecated) used to be used for virtualization](docs/why-vagrant.md) * [A case for supporting truncated files with loopback block devices](docs/testing-with-loopback.md) * [Seeing more issues with loopback / truncated files setup](docs/seeing-more-issues.md) * [Adding a new workflow to kdevops](docs/adding-a-new-workflow.md) @@ -347,10 +344,8 @@ Below are sections which get into technical details of how kdevops works. * [Motivation behind kdevops](docs/motivations.md) * [Linux distribution support](docs/linux-distro-support.md) * [Overriding all Ansible role options with one file](docs/ansible-override.md) - * [kdevops Vagrant support](docs/kdevops-vagrant.md) * [kdevops terraform support - cloud setup with kdevops](docs/kdevops-terraform.md) * [kdevops local Ansible roles](docs/ansible-roles.md) - * [Tutorial on building your own custom Vagrant boxes](docs/custom-vagrant-boxes.md) License ------- diff --git a/docs/ansible-roles.md b/docs/ansible-roles.md index dfb05b9fd..e07595431 100644 --- a/docs/ansible-roles.md +++ b/docs/ansible-roles.md @@ -2,12 +2,10 @@ The following local ansible roles are used: - * [update_ssh_config_vagrant](./playbooks/roles/update_ssh_config_vagrant/README.md) * [devconfig](./playbooks/roles/devconfig/README.md) * [create_partition](./playbooks/roles/create_partition/README.md) * create_data_partition: creates the data partition, uses the `create_partition` role * [install_terraform/](./playbooks/roles/install_terraform/README.md) - * [install_vagrant_boxes](./playbooks/roles/install_vagrant_boxes/README.md) * [libvirt_user](./playbooks/roles/libvirt_user/README.md) * [update_ssh_config_vagrant](./playbooks/roles/update_ssh_config_vagrant/README.md) diff --git a/docs/custom-vagrant-boxes.md b/docs/custom-vagrant-boxes.md deleted file mode 100644 index aa73a4266..000000000 --- a/docs/custom-vagrant-boxes.md +++ /dev/null @@ -1,581 +0,0 @@ -# Creating your own custom Vagrant boxes or qcow2 virtual images - -You can create your own custom Vagrant boxes if the publicly available -Vagrant boxes do not suit your needs. We document how to do this here. -One reason might be you are an Enterprise Linux distribution and don't -have public Vagrant boxes for older releases you might still support -but want the benefit of having Vagrant boxes to work with kdevops -kernel-ci. Another reason might be you just cannot legally share you -images, for one reason or another. Another reason is you may have some -new technology which is not yet easily available on distribution kernels -and want to enable folks to test technology on some development subsystem -or linux-nxt. - -## Re-using an existing box for development - -If you are doing Linux kernel development you may want to just enable -a QA or other developers to quickly test a built kernel for you. -If you don't want to do a full fresh install of a distribution you can -opt to re-use a distribution Vagrant box and just augment it with a -custom kernel build. This section documents how to do that with a demo -of a successful box built using this technique. - -This is the lazy developer approach to customizing a Vagrant box for Linux -kernel development. This involves four steps: - - * 1) One is getting your kernel binary and modules - * 2) The GRUB configuration stuff right. - * 3) Edit the Vagrantfile to remove stupid stuff - * 4) Building the tarball - -We break this down below. - -### Getting your kernel over - -From a libvirt perspective Vagrant boxes are just compressed tarballs -with a qcow2 file. So to hack on one first download the box. So for -example if we visit the [debian/testing64](https://app.vagrantup.com/debian/boxes/testing64) -page there you will see a [libvirt download URL](https://app.vagrantup.com/debian/boxes/testing64/versions/20220626.1/providers/libvirt.box) -with the box file. - -So we do: - -```bash -wget https://app.vagrantup.com/debian/boxes/testing64/versions/20220626.1/providers/libvirt.box - -sha1sum libvirt.box -06b07c0d0b78df5369d9ed35eaf39098c1ec7846 libvirt.box - -file libvirt.box -libvirt.box: gzip compressed data, from Unix, original size modulo 2^32 1197363200 -``` - -The file can be decompressed as a regular tarball. Since it has no -directory in it you want to copy the file to another directory and uncompress -there, otherwise it will clutter your current directory: - -```bash -mkdir box-dev -cp libvirt.box box-dev -cd box-dev -tar zxvf libvirt.box -``` - -So you will see 3 files, one just a qcow2 file the other expresses -how big of a drive was used to create this qcow2 file along with a -provider, and the Vagrantfile defines how to initialize this qcow2 file -with libvirt: - -```bash -ls -1 - -box.img -metadata.json -Vagrantfile - -file box.img -box.img: QEMU QCOW2 Image (v3), 21474836480 bytes - -cat metadata.json -{ - "provider" : "libvirt", - "format" : "qcow2", - "virtual_size" : 20 -} - -cat Vagrantfile -# -*- mode: ruby -*- -# vi: set ft=ruby : - -Vagrant.configure("2") do |config| - - config.vm.post_up_message = "Vanilla Debian box. See https://app.vagrantup.com/debian for help and bug reports" - - # workaround for #837992 - # use nfsv4 mode by default since rpcbind is not available on startup - # we need to force tcp because udp is not available for nfsv4 - config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_version: "4", nfs_udp: false - - # Options for libvirt vagrant provider. - config.vm.provider :libvirt do |libvirt| - - # A hypervisor name to access. Different drivers can be specified, but - # this version of provider creates KVM machines only. Some examples of - # drivers are kvm (QEMU hardware accelerated), qemu (QEMU emulated), - # xen (Xen hypervisor), lxc (Linux Containers), - # esx (VMware ESX), vmwarews (VMware Workstation) and more. Refer to - # documentation for available drivers (http://libvirt.org/drivers.html). - libvirt.driver = "kvm" - - # The name of the server, where libvirtd is running. - # libvirt.host = "localhost" - - # If use SSH tunnel to connect to Libvirt. - libvirt.connect_via_ssh = false - - # The username and password to access Libvirt. Password is not used when - # connecting via SSH. - libvirt.username = "root" - #libvirt.password = "secret" - - # Libvirt storage pool name, where box image and instance snapshots will - # be stored. - libvirt.storage_pool_name = "default" - - # Set a prefix for the machines that's different than the project dir name. - #libvirt.default_prefix = '' - end -end -``` - -And so to hack on the qcow file we just use nbd: - -```bash -sudo qemu-nbd --connect=/dev/nbd0 box.img -mkdir debian-testing-root-vagrant -sudo mount /dev/nbd0p1 ./vanilla-debian-zns/debian-testing-root-vagrant -``` - -When you finish just do: - -```bash -sudo modprobe nbd max_part=8 -sudo umount debian-testing-root-vagrant -sudo qemu-nbd --disconnect /dev/nbd0 -``` - -It is important to run the disconnect command before copying the box file as -backups or using it for anything. - -What I do then is use a kdevops linux-next guest to compile linux-next or -whatever I want, and then I use a two step process. One to scp the modules -directory locally, and the respective `/boot/*$(uname -r)*` files over to -a new directory and then install these on the target. Then you need to configure -the GRUB console so `sudo virsh console ` works and you also want to -update the GRUB menu. That is covered in the next subsection. - -### Getting your kernel over - -OK now you just need to update the `/etc/default/grub` file and also the -`/boot/grub/grub.cfg` file. Editing `/etc/default/grub` is easy you can -just run your editor on the mounted partition for the file and ensure -you have these entries: - -``` -GRUB_DEFAULT=0 -GRUB_TIMEOUT=5 -GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` -GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0" -GRUB_CMDLINE_LINUX="console=tty0 console=tty1 console=ttyS0,115200n8" - -GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --parity=no --stop=1" -GRUB_TERMINAL="console serial" -GRUB_DISABLE_SUBMENU=y -``` - -The last part of this file helps ensure you can get to pick a different -kernel at boot through the GRUB prompt using the serial console -(`virsh console`), however sadly it seems the GRUB version on the Debian -testing as of today doesn't work with this yet, so this step could be enhanced -to enable more flexibility to the user from the start. Until this is fixed then -developers have to do the work manually to perhaps update GRUB to get this -fixed. - -The last step is then to update the `/boot/grub/grub.cfg` file. -To do this, I just have two guests running: - - * dev: some development system where I compile and install some kernel - * baseline: a fresh Debian testing guest just brought up with Vagrant - -And then I scp to it the kernel / modules from dev over, run update-grub -and copy its grub.cfg file over. Something like the following: - -```bash -mkdir -p tmp/boot -scp -r dev:/lib/modules/5.19.0-rc4-next-20220629/ tmp/ -scp -r dev:/boot/*5.19.0-rc4-next-20220629* tmp/ - -scp -r tmp/boot/* baseline:/boot/ -scp -r tmp-provision-dir/5.19.0-rc4-next-20220629 baseline:/lib/modules/ -ssh baseline sudo update-grub -scp baseline:/boot/grub/grub.cfg tmp -``` - -OK so finally we can copy that grub.cfg to the mounted nbd partition and -hope that works. - -### Editing your Vagrantfile to remove stupid stuff - -By default Vagrant boxes enable sharing your directory to the guest -through NFS. From a Linux kernel development perspective this is just -lunacy. And so I like to disable it. By default then Debian uses this -for its sync thing - -``` - config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_version: "4", nfs_udp: false -``` - -Replace this with the more sane which disables this: - -``` - config.vm.synced_folder './', '/vagrant', type: '9p', disabled: true, accessmode: "mapped", mount: false -``` - -You may also want to edit the `config.vm.post_up_message` with whatever. - -``` - config.vm.post_up_message = "this is kernel build for send bug reports to ignore@ignore.org" -``` - -### Example network name resolution - -Most distros use udev for consistent names for networking interfaces. If -you just want to get a box out which will work fast the best way is to just -append to your GRUB kernel parameter: - -``` -GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0" -``` - -### Example network DHCP fix - -On a basic debian console install, so where no Network Manager is installed, -you want to just have something simply like this, after testing that the -default network name that comes up is eth0: - -``` -# cat /etc/network/interfaces -# interfaces(5) file used by ifup(8) and ifdown(8) -# Include files from /etc/network/interfaces.d: -source-directory /etc/network/interfaces.d - -# The loopback network interface -auto lo -iface lo inet loopback - -# The primary network interface -allow-hotplug eth0 -iface eth0 inet dhcp -``` - -### Ensuring ssh works - -You will want to ensure the user ~vagrant has a .ssh/ directory with -chmod 700 permissions and the vagrant ssh key installed by default. -When vagrant detects this a new one random one is replaced. - -https://github.com/hashicorp/vagrant/tree/main/keys - -So just do: - -```bash -mkdir .ssh -chmod 700 .ssh -echo ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== vagrant insecure public key >> authorized_keys -``` - -### Creating the Vagrant new box file tarball - -To create the box file you just tar it up. Assuming you want maximum -compression: - -```bash -tar -cvf ../mcgrof-20220629.box box.img metadata.json Vagrantfile -I "gzip --best" -``` - -You can now upload this box on the Vagrant cloud and use it with the -nice shorthands provided. - -## A fresh install - -To try to save the most amount of space you want to do a fresh install. -This section documents how to do that. - -First you'd install a guest using virt-install, an example script which -you can extend to your own needs is the -[virt-install-demo.sh](docs/virt-install-demo.sh). -There are a a series of adjustments that needed to be made for guests -to work for older kernel releases, should you need that. This is all -documented below. - -But below is an example simple script - - -```bash -virt-install --virt-type kvm \ - --name lio \ - --arch x86_64 \ - --cpu host \ - --location /home/mcgrof/debian-testing-amd64-netinst.iso \ - --os-variant debiantesting \ - --memory 8192 --vcpus 8 \ - --disk pool=data3-xfs,size=20,bus=virtio,format=qcow2 \ - --graphics none \ - --network network=vagrant-libvirt-private,model=virtio \ - --console pty,target_type=serial \ - --debug \ - --extra-args "console=ttyS0" -``` - -## Extending the Vagrant box definition - -A Vagrant box is essentially a tarball (gzip, xc are both supported) with a -qcow2 image and a small metadata file explaining how large the drive for the -guest is. The Vagrant box also ensures that the guest brought up will also -work on any new system, and so a few things need to be done to ensure for -instance that the network interface will get a DHCP address successfully, and -that you can ssh into the system. So a way to deal with moving guests around -the `cloud` are needed, an example is avoiding -`/etc/udev/rules.d/70-persistent-net.rules` upon first boot on some SLE -systems. - -Standard userspace development needs are typically met with the above -requirements. Kernel development however, have more more needs. Extensions -can be made by you so that the custom Vagrant boxes you build extend -what is promised by a Vagrant box, with other things which kernel developers -would typically prefer to have set on the system. This can save time -on bringup. Kdevops does a slew of things to help with this for you, like -setting up the serial console, but if Vagrant boxes already have these things -done on them that is a step which could be skipped. - -Below we provide a recipe of items which can be done to help on a fresh install -of a Linux distribution on a qcow2 image so that it is easier to test new -kernels and debug them. The standard Vagrant box definition *only* requires a -guest to come up, and to be able to ssh into them with the Vagrant user. - - * 1) root/vagrant user password is vagrant - * 2) vagrant user on /etc/sudoers does not need a password to gain root - * 3) vagrant user has an insecure SSH key installed to enable adding a new random one - * 4) Disable the firewall and AppArmor - * 5) Deal with persistent net rules - * 6) Ensure DHCP will work on the first network interface - * 7) Ensure the console is allowed - * 8) Ensure the correct disk size is used on the metadata json file - * 9) Try to use disk partitions by UUID on /etc/fstab - * 10) GRUB disk setup with UUID - * 11) GRUB console setup - * 12) Address lack of virtio - * 13) Address changes in sudo for old systems - -These all deserve their own attention so a section is provided for them below. - -### root / vagrant password - -Although no password is needed, just to ensure one is set the `vagrant` password -is set, just in case you need to use it. - -### vagrant sudoers - -The goal is to never have to use root directly since the boxes are for development -purposes, and so the following entry is expected: - -``` -vagrant ALL=(ALL) NOPASSWD: ALL -``` - -### vagrant user has an insecure SSH key installed - -Vagrant publishes an arbitrary public static SSH public and private key, so -that if it is detected a random SSH key is instead generated and used and -installed. - -Using a random SSH key for each host is a better idea due to possible -risks of guests being left `spawned` and then `pawned` by motivated eager -beavers for a key the entire internet has access to. - -You can surely use your own key as well, however, when sharing Vagrant boxes -you likely don't want to be sharing SSH keys. - -### Disable the firewall and AppArmor - -You are not trying to secure a bank when running a guest for -kernel development, so running a firewall and apparmor is just -typically noise. This is unless of course if you are testing apparmor -or firewall changes to the kernel. - -The firewall and AppArmor can be enabled after initialization, however, -if you really need it. - -### Deal with persistent net rules - -Each Linux distribution has dealt with a way to keep MAC addresses mapped -to a specific interface name. This is to allow a network card to always get -the same IP address, in case it changes the bus it uses on a system. - -Spawning a guest from a Vagrant box means we *want* a different MAC -address for each new guest. This also means we want the first interface -to take the first possible interface name, which will be used for DHCP -purposes after bootup. - -### Ensure DHCP will work on the first network interface - -We expect at least one ethernet interface to come up so that it can get an IP -address and so that we can then SSH into it. Using a network interface just to -communicate to guests is rather archaic, however, it is the current norm. - -A Vagrant box *expects* a random interface to be spawned with it, and we -want to just ensure it, whatever it is, will ask for an IP address via -DHCP. We want to use a mechanism that will work, if possible, for older -systems as well. - -The following recipe works from SLES12-SP3 down to SLES10-SP3 as -an example: - -```bash -if [ -d ] /etc/sysconfig ]; then - cat << FIXIFCGHETH0 > /etc/sysconfig/network/ifcfg-eth0 -DEVICE=eth0 -BOOTPROTO=dhcp -ONBOOT=yes -STARTMODE='auto' - -FIXIFCGHETH0 -``` - -### Ensure the correct disk size is used on the metadata json file - -Vagrant boxes have a metadata json file. If you create a qcow2 image -as follows: - -``` -qemu-img create -f qcow2 foo.qcow2 50G -``` - -Then ensure you have 50 as your size for your metadata.json file: - -``` -{ - "provider" : "libvirt", - "format" : "qcow2", - "virtual_size" : 50 -} -``` - -Note that the Vagrant libvirt provider does not seem to provide support -yet for versioning. - -### Try to use disk partitions by UUID on /etc/fstab - -Some releases do not use /dev/disk/by-uuid labels on /etc/fstab. This -poses a risk when trying to move a guest qcow2 image file from one -system to another. We want something static, and the UUID assigned to -partitions addresses this problem. - -This however means that if you are creating your own custom Vagrant -box or installing your own new fresh kernel you may have to take steps -to ensure the UUID is used instead of the raw /dev/vda or alternative -device disk name. - -### GRUB disk setup with UUID - -As an example, GRUB 0.97 is used on SLE10-SP3, SLE11-SP1, and SLE11-SP4. On -these releases you must ensure that the same /dev/disk/by-uuid is used so that -that a Vagrant box can function on new systems. You do this by editing -/boot/grub/menu.lst and ensuring the appropriate full path /dev/disk/by-uuid/ is -used for the partition in question. - -On SLES10-SP3 swap partitions lacked a respective UUID, and so the -resume entry must be removed. - -SLES12-SP1 and newer use GRUB2, and started using UUID=id as a shortcut on -/etc/fstab and /etc/default/grub, and so no modifications are needed there. - -### GRUB console setup - -As a kernel developer you want to be able to pick what kernel boots -easily. Today, we do this via the console. So we must ensure the console -works on the guest. We support GRUB2 (GRUB) and GRUB 0.97 (GRUB Legacy). - -#### GRUB 0.97 console setup - -On GRUB 0.97 based systems you must add the following to the top of the -/boot/grub/menu.lst file (when in doubt check one of the custom Vagrant -boxes): - -``` -serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 -terminal --timeout=4 serial console -``` - -Replace `gfxmenu` with `menu` on /boot/grub/menu.lst. - -Below are the base releases of GRUB 0.97 used on our older SLE releases: - - * sles10sp3: grub-0.97-16.25.9 - * sles11sp1: grub-0.97-162.9.1 - * sles11sp4: grub-0.97-162.172.1 - -Ensure any `quiet` entry is removed from the kernel command lines. - -#### GRUB2 console setup - -If you install an ISO on a guest using the console the installer has the sanity -to set up *most* of the right setting for you. However, on SLE12-SP1 you must -make the following change on /etc/default/grub: - -``` --GRUB_TERMINAL=console -+GRUB_TERMINAL="console serial" -``` - -Also ensure GRUB_CMDLINE_LINUX_DEFAULT has the entry `quiet` removed. - -### Address lack of virtio - -Certain modern Linux releases releases support virtio drivers for networking, -or storage. Since Vagrant uses KVM and KVM relies on QEMU, when virtio is not -available emulation is needed. Vagrant is controlled via its Vagrantfile, and -users of a Vagrant box can specify one. However sensible defaults must also be -set and provided on a base Vagrantfile for a Vagrant box. The lack of a virtio -driver then is codified into the Vagrantfile used to build the first Vagrant -box. A Vagrant box is nothing more than a tarball (gzip or xz, use xz, it has -better compression) with the guest qcow2 image, the metadata.json file shown -above, and an initial Vagrantfile. - -Below we document the currently needed modifications needed to the Vagrantfile -for our older Linux distributions, we use older SUSE Linux releases as -example which were targeted to create Vagrant boxes for kernel development -and testing. - -#### Disable default /vagrant nfs sharing for all releases - -Vagrant boxes by default share folders under the current directory via NFS -to the guests you create. This doesn't work so well for all hosts, and sharing -via NFS isn't the best really. We disable NFS sharing as the default then. - -This applies to SLE12-SP3 and older releases. - -#### Disable virtio drives - -SLE10-SP3 doesn't have virtio block driver, and so the root drive uses scsi as the -emulated backend for the drive. Note that currently we still use IDE drives for -the other alternative drives, given using scsi doesn't work at the moment. This -discrepancy should be resolved. - -This is done as follows on the respective Vagrantfile: - -``` - libvirt.disk_bus = "scsi" -``` - -#### Disable virtio networking - -SLE10-SP3 doesn't have a virtio network driver, and so the ne2k_pci network driver -is emulated. - -This is done as follows on the respective Vagrantfile: - -``` - libvirt.nic_model_type = "ne2k_pci" -``` - -### Address changes in sudo for old systems - -SLE10-SP3 has an old version of sudo which lacks the `-E` argument. And since -the default in Vagrant is to use -E, we have to disable this for SLE10-SP3. - -This is done as follows on the respective Vagrantfile: - -``` - config.ssh.sudo_command = "sudo -H %c" -``` diff --git a/docs/cxl.md b/docs/cxl.md index f41e489c1..5582216e3 100644 --- a/docs/cxl.md +++ b/docs/cxl.md @@ -3,10 +3,8 @@ kdevops has support bringing up a CXL development environment and testing. This documents this support. -Current support for CXL on kdevops relies on vagrant, support for -[libguestfs](https://libguestfs.org/) is currently under investigation but -will rely on using a python script to dynamically create XML requirements. -The documentation below assumes vagrant will be used for now. +Current support for CXL on kdevops relies on libguestfs. Support was +originally developed for Vagrant but has since been removed. You can either use virtualized CXL devices or you can use [PCIe passthrough](docs/libvirt-pcie-passthrough.md) to passthrough real diff --git a/docs/kdevops-configuration.md b/docs/kdevops-configuration.md index ce1799ff1..10fe4eb54 100644 --- a/docs/kdevops-configuration.md +++ b/docs/kdevops-configuration.md @@ -8,7 +8,7 @@ make help # Configuring kdevops -kdevops provides support for vagrant, Terraform, bare metal, and optionally +kdevops provides support for Terraform, bare metal, and optionally helps you install and configure libvirt, as well as let you choose which git tree for Linux to compile, install and boot into, along with which git tag or commit ID use, and apply any extra patches you might have. The last step of @@ -20,7 +20,7 @@ few more elaborate projects are referenced later. What a target system may need will vary depending on your needs and your preferences and so the Linux modeling variability language, Kconfig, has been embraced to allow users to configure how kdevops is to be used. You choose -whether or not to use vagrant, Terraform, bare metal, and what bells or +whether or not to use Terraform, bare metal, and what bells or whistles to turn on or off. To configure kdevops use: diff --git a/docs/kdevops-terraform.md b/docs/kdevops-terraform.md index e6a518c7f..cd5665b23 100644 --- a/docs/kdevops-terraform.md +++ b/docs/kdevops-terraform.md @@ -69,8 +69,7 @@ writing we support this for all cloud providers we support. After `make bringup` you should have had your SSH configuration file updated automatically with the provisioned hosts. The Terraform module -`add-host-ssh-config` is used to do the work of updating your SSH configuration, -a module is used to share the code with provisioning with vagrant. +`add-host-ssh-config` is used to do the work of updating your SSH configuration. The Terraform module on the registry: @@ -80,11 +79,10 @@ The Terraform source code: * https://github.com/mcgrof/terraform-kdevops-add-host-ssh-config -Because the same code is shared between the vagrant Ansible role and the -Terraform module, a git subtree is used to maintain the shared code. The -Terraform code downloads the module on its own, while the code for -the Vagrant Ansible role has the code present on the kdevops tree as -part of its local directories in under: +Because the same code is shared between the Ansible role and the +Terraform module, a git subtree is used to maintain the shared code. +The Terraform code downloads the module on its own, while the role has +the code present in the kdevops tree under: * `playbooks/roles/update_ssh_config_vagrant/update_ssh_config/` diff --git a/docs/kdevops-vagrant.md b/docs/kdevops-vagrant.md deleted file mode 100644 index 1e214d096..000000000 --- a/docs/kdevops-vagrant.md +++ /dev/null @@ -1,130 +0,0 @@ -# Vagrant support - localized VMs - -Vagrant is used to easily deploy non-cloud virtual machines. Below are -the list of providers supported: - - * VirtualBox - * libvirt (KVM) - -The following Operating Systems are supported: - - * OS X - * Linux - -## Running libvirt as a regular user - -kdevops is designed be used without requiring root privileges, however your -user must be allowed to run sudo without a password, and for the regular -user to also be able to run libvirt commands as a regular user. We have an -Ansible role which takes care of dealing with this for you. You'd only use -libvirt if using Linux. - -## Node configuration - -The term `host` is often used to describe `localhost`, and so to help -distinguish `localhost` from your target hosts you'd use for development we -refer to target hosts for development as `nodes`. - -We use a yml file to let you describe your project's nodes and how to configure -them. You configure your node target deployment on the -``vagrant/${PROJECT}_nodes.yaml`` file by default. Since this file is committed -into git, if you want to override the defaults and keep that file outside of -git you can use use the file: - - * ``vagrant/${PROJECT}_nodes_override.yaml`` - -If you prefer a different override file, you can use the environment variable -``KDEVOPS_VAGRANT_NODE_CONFIG`` to define the vagrant host description file -used. - -## Provisioning with vagrant - -If on Linux we'll assume you are using KVM / libvirt. If on OS X we'll assume -you are using VirtualBox. If these assumptions are incorrect you can override -on the configuration file for your node provisioning. For instance, for this -demo you'd use `vagrant/kdevops_nodes.yaml` and set the `force_provider` variable -to either "libvirt" or "kvm". You can also use environment variables to -override the provider: - - * KDEVOPS_VAGRANT_PROVIDER - -You are responsible for having a pretty recent system with some fresh -libvirt, or VirtualBox installed. You are encouraged to use the latest release -for your OS and preferably a rolling Linux distribution release. A VirtualBox -which supports NVMe is required. - -To ramp up your guests with vagrant: - -```bash -make -make bringup -``` - -The last step in the above `make bringup` is to run optional Ansible roles -which can enable direct ssh access to nodes and also run a bit of basic -provisioning. Although vagrant has direct support for running Ansible we do -not make use of this mechanism as it has proven to be fragile before. If -`CONFIG_KDEVOPS_SSH_CONFIG_UPDATE` is enabled your ssh configuration -is updated to enable Ansible to connect to the nodes which have come up. If -`CONFIG_KDEVOPS_ANSIBLE_PROVISION_PLAYBOOK` is enabled then the Ansible -role configured in `CONFIG_KDEVOPS_ANSIBLE_PROVISION_PLAYBOOK` is the first -Ansible to run against nodes to do initial provisioning which by default is the -`devconfig` Ansible role. This is all done as part of the `bringup_vagrant` -target on the file `scripts/vagrant.Makefile`. The roles used are: - - * [update_ssh_config_vagrant](playbooks/roles/update_ssh_config_vagrant/README.md) - * [devconfig](playbooks/roles/devconfig/README.md) - -At this point basic initial provisioning is complete. - -### Code changes for update_ssh_config_vagrant - -The Ansible role `update_ssh_config_vagrant` is used to help update your -ssh configuration when using vagrant. The actual code used is a python -script which is also shared for kdevop's support of Terraform for cloud -provisioning support. The `update_ssh_config_vagrant` Ansible role in -kdevops has the for for the python script locally by using a git subtree. -Updates to actual python code used should be made atomically so that these -changes get pushed back upstream. For more details refer to the following -documentation: - - * [update_ssh_config shared code documentation](playbooks/roles/update_ssh_config_vagrant/update_ssh_config/README.md) - -## Destroying provisioned nodes with vagrant - -You can just use the helper: - -```bash -make destroy -``` - -Or you can either destroy directly with vagrant: - -```bash -cd vagrant/ -vagrant destroy -f -rm -rf .vagrant -``` - -Or you can just use virsh directly, if using KVM: - -```bash -sudo virsh list --all -sudo virsh destroy name-of-guest -sudo virsh undefine name-of-guest -``` - -## Limiting vagrant's number of boxes - -By default using vagrant will try to create *all* the nodes specified on -your configuration file. By default this is `vagrant/kdevops_nodes.yaml` for -this project, and there are currently 2 nodes there. If you are going to just -test this framework you can limit this initially using environment variables: - -```bash -export KDEVOPS_VAGRANT_LIMIT_BOXES="yes" -export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1 -``` - -This will ensure only the first host, for example, would be created and -provisioned. diff --git a/docs/kernel-ci/kdevops-subtree-recommeded.md b/docs/kernel-ci/kdevops-subtree-recommeded.md index c4dfb2b10..7ff5ca99c 100644 --- a/docs/kernel-ci/kdevops-subtree-recommeded.md +++ b/docs/kernel-ci/kdevops-subtree-recommeded.md @@ -8,7 +8,7 @@ tree as a git sub tree might be: * keeping track of expunges for baselines for releases which are not yet public - * adding support vagrant images for releases which are not yet public + * adding support images for releases which are not yet public * dealing with internal R&D registration (consider enterprise Linux registration) of guests to a subscription service diff --git a/docs/lbs.md b/docs/lbs.md index 9742fe1d1..ab55f9bad 100644 --- a/docs/lbs.md +++ b/docs/lbs.md @@ -92,20 +92,7 @@ and if you later want to, use ext4 on the same drive after wiping XFS. ## Experimenting with pure-iomap -Kdevops provides its own debian-testing vagrant image which supports XFS as the main -root image, and thus could also enable experimenting with pure-iomap. Pure-iomap -allows the `bdev cache` to use IOMAP instead of buffer-heads when doing disk -partition scanning on bootup. - -Enable: - - * `CONFIG_VAGRANT_KDEVOPS_DEBIAN_TESTING64_XFS_20230427` - -This effectively enables the vagrant image: - - * [kdevops debian-xfs-20230427](https://app.vagrantup.com/linux-kdevops/boxes/debian-xfs-20230427/) - -If you'd like to work on your own image see [kdevops docs on building custom vagrant images](https://github.com/linux-kdevops/kdevops/blob/master/docs/custom-vagrant-boxes.md). +Pure-iomap allows the `bdev cache` to use IOMAP instead of buffer-heads when doing disk partition scanning on bootup. If you want to build your own image see the documentation on creating custom images. # Regressions large-block-next diff --git a/docs/libvirt-pcie-passthrough.md b/docs/libvirt-pcie-passthrough.md index f9ff1d183..18781671b 100644 --- a/docs/libvirt-pcie-passthrough.md +++ b/docs/libvirt-pcie-passthrough.md @@ -30,8 +30,7 @@ not everyone wants these features. ## Enable kdevops PCIe passthrough support -PCIe passthrough support is currently only available when you select to -use vagrant with libvirt. The respective Kconfig option is +PCIe passthrough support is available when using libvirt. The respective Kconfig option is `CONFIG_KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH`. If you enable that you then get to pick what technique you wish to use to @@ -97,7 +96,7 @@ to review how this is done generically with kdevops. You don't need to read this if you are using `make dynconfig`. To get this to work you must modify permissions of some sysfs files so that -vagrant/libvirt will work properly. You also must make sure the vfio devices +libvirt will work properly. You also must make sure the vfio devices are accessible by the libvirt group. Scripts are provided to do all the work for you, but you must determine the PCIe ID's of the devices you want to passthrough. The following is an example @@ -119,15 +118,12 @@ above example, you would have a `pcipassthrough` option with the configuration for your given device ```yaml -vagrant_boxes: - - name: kdevops-btrfs-zns - ip: 172.17.8.101 - pcipassthrough: - zns1: - domain: 0x0000 - bus: 0x2d - slot: 0x00 - function: 0x0 +pcipassthrough: + zns1: + domain: 0x0000 + bus: 0x2d + slot: 0x00 + function: 0x0 ``` From here you will be able to run `make bringup` and the PCIe passthrough will diff --git a/docs/linux-distro-support.md b/docs/linux-distro-support.md index f8ab74b62..24ed4731b 100644 --- a/docs/linux-distro-support.md +++ b/docs/linux-distro-support.md @@ -13,8 +13,7 @@ Distributions are supported as new users add support for them. Adding support for a new distribution typically just consists of updating the kdevops Ansible roles with support for doing a mapping of package names, package manager updates, and ensuring your distribution can install the latest -version of vagrant and Terraform. Because you *want* the latest version of -vagrant and Terraform rolling Linux distributions are encouraged to be used. +version of Terraform. Rolling Linux distributions are encouraged to be used. Currently supported Linux distributions: * Debian testing @@ -22,9 +21,9 @@ Currently supported Linux distributions: * OpenSUSE Tumbleweed * Ubuntu 21.10 -If your distribution does not have vagrant and Terraform packaged, support -is provided to download the latest releases via the published zip files, -however this can get complex quite fast due to the dependency chain. +If your distribution does not have Terraform packaged, support is provided +to download the latest release via the published zip files, however this +can get complex quite fast due to the dependency chain. ## Target Linux distributions support diff --git a/docs/requirements.md b/docs/requirements.md index eddf50038..c637c3aa6 100644 --- a/docs/requirements.md +++ b/docs/requirements.md @@ -17,12 +17,6 @@ Then you can now run: # Supported base distributions for command and control -Examples of well tested rolling distributions recommended if using vagrant: - - * Debian testing - * OpenSUSE Tumbleweed - * Fedora - * Latest Ubuntu - -If using Terraform just ensure you can upgrade Terraform to the latest release -regularly. +Examples of well tested rolling distributions include Debian testing, +OpenSUSE Tumbleweed, Fedora and the latest Ubuntu. Ensure you can +upgrade Terraform to the latest release regularly if you rely on it. diff --git a/docs/running-make.md b/docs/running-make.md index 88aa6d2b7..3a86e1cc2 100644 --- a/docs/running-make.md +++ b/docs/running-make.md @@ -35,15 +35,3 @@ rm -f hosts make hosts ``` - * If using virtualization it will generate the dynamic Vagrant and vagrant - nodes file, `kdevops_nodes.yaml`. - - It is *not* safe to destroy the Vagrantfile if you have done a git fetch - and reset for kdevops, given that vagrant requires you to never modify - your Vagrantfile *after* you have instantiated guests. kdevops provides - a guard file for you so you don't shoot yourself in the foot and make - commands won't regenerate the file for you unless you remove this guard. - - The files in question is `vagrant/Vagrantfile`. The respective configuration - for the nodes, `vagrant/kdevops_nodes.yaml` should not be updated either, - because the Vagrantfile relies on it. diff --git a/docs/the-gen-nodes-ansible-role-vagrant.md b/docs/the-gen-nodes-ansible-role-vagrant.md deleted file mode 100644 index 0bf907009..000000000 --- a/docs/the-gen-nodes-ansible-role-vagrant.md +++ /dev/null @@ -1,78 +0,0 @@ -# Vagrant gen_nodes work - -The `gen_nodes` ansible role is used to let us generate certain target files we -need upon bringup. The amount of files it generates will depend on the features -you have enabled. For local virtualization we support vagrant and the files -generated are listed below. - - * The `KDEVOPS_NODES` file: defines which nodes to create - * The `vagrant/Vagrantfile`: a dynamic Vagrantfile - -## KDEVOPS_NODES and KDEVOPS_NODES_TEMPLATE for vagrant - -If you have local virtualization enabled vagrant then we default these: - - * `KDEVOPS_NODES` as `vagrant/kdevops_nodes.yaml` - * `KDEVOPS_NODES_TEMPLATE` is set to the jinja2 template `$(KDEVOPS_NODES_ROLE_TEMPLATE_DIR)/kdevops_nodes_split_start.j2.yaml`. - -Your workflow can override this to something different if needed. - -### Dynamic vagrant/kdevops_nodes.yaml file - -Although the top level ansible hosts file is already dynamic -(see [dynamic kdevops ansible hosts file)](docs/the-gen-hosts-ansible-role.md)) -we currently also generate another yaml file which is used by both local -virtualizaition and cloud environment for node definitions. This file -is a bit more complex given we also extend it with a set of libvirt options -for dynamic features to hosts, to do this jinja2 routines are used. - - * [kdevops dynamic ansible hosts file](playbooks/roles/gen_nodes/templates/kdevops_nodes_split_start.j2.yaml) - * [kdevops dynamic ansible hosts file](playbooks/roles/gen_nodes/templates/hosts.j2) - -As you will see, the `kdevops_nodes_split_start.j2.yaml` starts off with -a set of variables. Most of these were defined and used before we started -embracing Kconfig, so one future work item is to try to see which ones -make sense to move to Kconfig and then `extra_vars.yaml` so we don't have them -in this file. - -The last part of the file is as follows - -``` -vagrant_boxes: -{% include './templates/hosts.j2' %} -``` - -This just calls the jinja2 helper `gen_nodes_list()` with a series of arguments. -This in turn just processes the loop of `gen_node()` for each node in the -array nodes_list. That routine will augment the series of requirements which -are node specific. For example if `passthrough_enable` is `True` it will augment -the node with PCIe passthrough options. - -#### Hyper dynamic qemu feature - -Support for [PCIe passthrough support docs](docs/libvirt-pcie-passthrough.md) is -accomplished by scraping your host system and generating dynamic Kconfig files. -These files are unique to your host and because of this kdevops is -`hyper dynamic`. kdevops uses this support to let you pick which target -nodes will get what features and extends qemu arguments for each guest. - -This demonstrate both how we both: - - * static Kconfig options for qemu per guest - * hyper dynamic Kconfig options for qemu per guest - -#### Static dynamic qemu features per guest - -Given dynamic Kconfig features are possible, it should be easy to then extend -vagrant support to also support different features which don't depend on your -host system, but rather are defined statically on everyone's Kconfig options. -This might be useful, for example, to extend CXL topologies statically. -However, considerations should be also taken to evaluate if a dynamic set -of CXL topologies *could* be inferred based on programming, how would we -define them? Evaluation for this should be done. - -If you want you can just define a custom `KDEVOPS_NODES_TEMPLATE` as well. - -## Related files - - * [Vagrant top level Makefile](scripts/vagrant.Makefile) diff --git a/docs/the-gen-nodes-ansible-role.md b/docs/the-gen-nodes-ansible-role.md index 916b848db..0c5e1de23 100644 --- a/docs/the-gen-nodes-ansible-role.md +++ b/docs/the-gen-nodes-ansible-role.md @@ -12,8 +12,8 @@ file. That's it. You then codify in the template file what you need using your configuration. The `gen_nodes` ansible role is in charge of generating node specific -files. The amount of files generated will depend on if you are using -local virtualization (vagrant) or cloud (terraform). We document both below. +files. The amount of files generated will depend on whether you are using +local virtualization or cloud (terraform). We document both below. For both cases we always generate the `KDEVOPS_NODES` file based on the jinja2 template `KDEVOPS_NODES_TEMPLATE`. @@ -34,9 +34,9 @@ KDEVOPS_NODES_ROLE_TEMPLATE_DIR := $(KDEVOPS_PLAYBOOKS_DIR)/roles/gen_nodes/temp The `KDEVOPS_NODES` and `KDEVOPS_NODES_TEMPLATE` is a top level Makefile variable set to empty at first. -If you have local virtualization enabled vagrant then we default these: +If local virtualization is enabled we default these: - * `KDEVOPS_NODES` as `vagrant/kdevops_nodes.yaml` + * `KDEVOPS_NODES` as `guestfs/kdevops_nodes.yaml` * `KDEVOPS_NODES_TEMPLATE` is set to the jinja2 template `$(KDEVOPS_NODES_ROLE_TEMPLATE_DIR)/kdevops_nodes_split_start.j2.yaml`. If using a cloud environment terraform will set these to be other files: @@ -48,5 +48,4 @@ Furthermore, your workflow can override this to something different if needed. Docs for each are split up: - * [gen_nodes for vagrant](the-gen-nodes-ansible-role-vagrant.md) * [gen_nodes for terraform](the-gen-nodes-ansible-role-terraform.md) diff --git a/docs/why-vagrant.md b/docs/why-vagrant.md deleted file mode 100644 index ac075bfe4..000000000 --- a/docs/why-vagrant.md +++ /dev/null @@ -1,66 +0,0 @@ -# Vagrant deprecation - -vagrant is not actively maintained so we have moved away from it for -new development / features, [libguestfs](https://libguestfs.org/) is the -focus of support for new features involving local virtualization. - -# Why Vagrant is used for virtualization - -There are a few reasons why kdevops has embraced Vagrant. Below we go through -each of them. - -## What is a Vagrant box anyway? - -First let's understand what a Vagrant box is. A Vagrant box is essentially a -tarball (gzip, xc are both supported) with a qcow2 image and a small metadata -file explaining how large the drive for the guest is. - -## Reducing bring up speed - -Hackers just want to get a guest up fast, slap a kernel on it as fast as -possible, and hope it comes up, and then run some tests or hack something up -on the kernel. The faster we can do this the better. - -The typical approach to using guests is to install a guest using an ISO, and -that takes time. Another way is to just keep copies around of some qcow2 images -and just copy them over when you want to do something new. This can become a -bit of a managing nightmare if you are doing this manually though. Vagrant -abstracts this for you, and essentially does just that. - -## Vagrant has sensible developer friendly settings - -If you are installing a guest with an ISO, you likely will then start doing -a few custom things as a developer. The first thing most developers do is -add a sudoers for your username. A Vagrant box already comes with these things -preset. Also, sensible defaults for the username and root password are set, -because we don't care about security when doing quick bringups for quick -development / testing. - -Another example setup which Vagrant takes care of is bringing up SSH and -letting you SSH to the guest right away. Below is a list of things Vagrant -boxes already come set up with, so you as a developer don't have to do this: - - * 1) root/vagrant user password is vagrant - * 2) Vagrant user on /etc/sudoers does not need a password to gain root - * 3) Vagrant can create a random SSH key for each guest - * 4) Deal with persistent net rules - * 5) Ensure DHCP will work on the first network interface - * 6) Ensure the console is allowed - * 7) Try to use disk partitions by UUID on /etc/fstab - * 8) GRUB disk setup with UUID - -If you'd like to learn more about this read the -[making custom vagrant boxes documentation](docs/custom-vagrant-boxes.md) - -## Supporting different virtualization technologies - -There are different software solutions available which can take -advantage of your architecture's virtualization features and control -guests. Examples are libvirt, VirtualBox. Vagrant abstracts the -virtualization solution used as a "provider" and each provider then -can support its own way to bring up guests. - -## Supporting different Operating Systems - -If we only supported libvirt it would mean you cannot use kdevops on Mac OS X. -OS X users can make user of virtualbox for kdevops. diff --git a/kconfigs/Kconfig.ansible_provisioning b/kconfigs/Kconfig.ansible_provisioning index 63f04306e..b5efc9909 100644 --- a/kconfigs/Kconfig.ansible_provisioning +++ b/kconfigs/Kconfig.ansible_provisioning @@ -187,10 +187,8 @@ config DEVCONFIG_SYSTEMD_JOURNAL_REMOTE_URL help This is used for the client /etc/systemd/journal-upload.conf URL line. By default we won't use SSL for now. If you should make sure the - IP address used here matches what the node should use. If using - libvirt then ensure it is the same for your virtualization setup. - If you are using vagrant on debian on the host it would seem the - current default should work. + IP address used here matches what the node should use. If using + libvirt then ensure it is the same for your virtualization setup. endif # DEVCONFIG_ENABLE_SYSTEMD_JOURNAL_REMOTE diff --git a/kconfigs/Kconfig.bringup b/kconfigs/Kconfig.bringup index a9aefc56e..95d00676a 100644 --- a/kconfigs/Kconfig.bringup +++ b/kconfigs/Kconfig.bringup @@ -59,7 +59,6 @@ config LIBVIRT default y source "kconfigs/Kconfig.guestfs" -source "vagrant/Kconfig" source "terraform/Kconfig" if LIBVIRT source "kconfigs/Kconfig.libvirt" diff --git a/kconfigs/Kconfig.libvirt b/kconfigs/Kconfig.libvirt index 1b8f4b95f..56335d695 100644 --- a/kconfigs/Kconfig.libvirt +++ b/kconfigs/Kconfig.libvirt @@ -18,9 +18,7 @@ config LIBVIRT_CONFIGURE in again, to ensure the new group takes effect. The goal in the configuration will be to ensure you can use libvirt to spawn guests as a regular user. You are encouraged to say y here unless you know - what you are doing or you already know this works. If you are unsure, - the litmus test for this is if you can run vagrant up, on any public - demo box available. + what you are doing or you already know this works. config LIBVIRT_VERIFY bool "Verify that a user can spawn libvirt as a regular user" @@ -30,7 +28,7 @@ config LIBVIRT_VERIFY To enable a user to be able to spawn libvirt guests as a regular user a user is typically added to a few groups. These groups are not effective immediately, and so before a user can assume that they - use Vagrant they must verify that the required groups are effective. + start guests they must verify that the required groups are effective. If you enable this option, we will spawn an Ansible role that will verify and ensure that your user is already part of these groups. You can safely say yes here. @@ -60,7 +58,7 @@ config LIBVIRT_URI_SYSTEM proper networkings via bridges or virtual networks. qemu:///system is generally what tools like virt-manager default to. - When this option is enabled vagrant's libvirt default built-in + When this option is enabled libvirt default built-in URI is used along with the default network management interface, libvirt socket, and the network interface assumed for bridging. @@ -92,7 +90,7 @@ config LIBVIRT_URI_SESSION you are doing custom networking stuff this may be more relevant for you. Fedora defaults to the session URI. - When this option is enabled we modify vagrant's libvirt default + When this option is enabled we modify libvirt default built-in URI for the session URI, and we also modify the default network management interface to be virbr0, the default socket is assumed to be /run/libvirt/libvirt-sock-ro. New Kconfig options @@ -120,14 +118,14 @@ config LIBVIRT_URI_PATH string "Libvirt QEMU URI to use" default "qemu:///system" if LIBVIRT_URI_SYSTEM || LIBVIRT_URI_CUSTOM default "qemu:///session" if LIBVIRT_URI_SESSION - help - By default Vagrant uses a qemu:///system URI which assumes the libvirt - daemon runs as a user other than the user which is running the vagrant - commands. Libvirt has support for running the libvirt daemon as other - users using session support. This will be modified to a session URI - if you enable LIBVIRT_URI_SESSION. You can however set this to - something different to suit your exact needs here. This is the value - passed to the vagrant-libvirt plugin libvirt.uri. You should not have + help + By default libvirt uses a qemu:///system URI which assumes the libvirt + daemon runs as a user other than the user running the commands. + Libvirt has support for running the libvirt daemon as other + users using session support. This will be modified to a session URI + if you enable LIBVIRT_URI_SESSION. You can however set this to + something different to suit your exact needs here. This is the value + passed to the libvirt plugin libvirt.uri. You should not have to modify this value if you selected LIBVIRT_URI_SYSTEM or LIBVIRT_URI_SESSION and are starting from a fresh 'make mrproper' setting on kdevops, the appropriate value will be set for you. @@ -139,14 +137,14 @@ config LIBVIRT_SYSTEM_URI_PATH default "qemu:///system" help This is the URI of QEMU system connection, used to obtain the IP - address for management. This is used for the vagrant-libvirt plugin - libvirt.system_uri setting. If for whatever reason this needs to + address for management. This is used for the libvirt plugin + libvirt.system_uri setting. If for whatever reason this needs to be modified you can do so here. Even if you are using session support you should leave this with the default qemu:///system setting as this is still used to ensure your guest's IP address will be - communicated back to Vagrant so it determines the guest is up and + communicated back to kdevops so it determines the guest is up and you can ssh to it. Setting this to qemu:///session still gets the - guest up but Vagrant won't know the guest is up, even though the + guest up but kdevops won't know the guest is up, even though the host can ssh to the guest. You should only modify this value if you know what you are doing. @@ -464,7 +462,7 @@ config HAVE_LIBVIRT_PCIE_PASSTHROUGH default $(shell, scripts/check_pciepassthrough_kconfig.sh passthrough_libvirt.generated) if HAVE_LIBVIRT_PCIE_PASSTHROUGH -source "vagrant/Kconfig.pcie_passthrough_libvirt" +source "kconfigs/Kconfig.pcie_passthrough_libvirt" endif # HAVE_LIBVIRT_PCIE_PASSTHROUGH choice @@ -968,7 +966,7 @@ config LIBVIRT_STORAGE_POOL_PATH_INFER_ADVANCED bool "Use an advanced smart inference for what storage pool path to use" help If you are a power user of kdevops you likely want to enable this. - By default vagrant will assume that if you don't have a virsh pool + By default libvirt will assume that if you don't have a virsh pool that the current directory will become the "default" storage pool path. This is rather silly for an advanced setup. Consider a setup where you have a set of different NVMe drivers mounted on different @@ -996,9 +994,9 @@ config LIBVIRT_STORAGE_POOL_PATH_INFER_ADVANCED that the heuristics will work on each distro with their own defaults. config LIBVIRT_STORAGE_POOL_PATH_CUSTOM_CWD - bool "Use the current vagrant working directory" + bool "Use the current kdevops working directory" help - Select this option if you want to use the vagrant directory inside + Select this option if you want to use the kdevops directory inside where you git cloned kdevops as the libvirt storage pool path where we'll download images and store images for guests spawned. If users git cloned kdevops somewhere in their home directory they'll have to @@ -1031,16 +1029,16 @@ config LIBVIRT_STORAGE_POOL_PATH_AUTO string default $(shell, ./scripts/get_libvirsh_pool_path.sh) if LIBVIRT_STORAGE_POOL_PATH_INFER_ADVANCED default "/var/lib/libvirt/images" if LIBVIRT_STORAGE_POOL_PATH_CUSTOM_DEFAULT_DISTRO - default $(shell, scripts/cwd-append.sh vagrant) if LIBVIRT_STORAGE_POOL_PATH_CUSTOM_CWD + default $(shell, scripts/cwd-append.sh guestfs) if LIBVIRT_STORAGE_POOL_PATH_CUSTOM_CWD help The path to use for the libvirt storage pool path. Since kdevops uses - Vagrant for virtualization this is also the path used to place the + libvirt for virtualization this is also the path used to place the additional NVMe drives created. kdevops adds a postfix "kdevops" to - this directory as it wants to allow Vagrant full control over that + this directory as it wants to allow libvirt full control over that directory. For instance if this is /var/lib/libvirt/images/ kdevops - will let Vagrant store images in /var/lib/libvirt/images/ and + will let libvirt store images in /var/lib/libvirt/images/ and the NVMe qcow2 files created will go in by default to the directory - /var/lib/libvirt/images/kdevops/.vagrant/nvme_disks/guest-hostname/. + /var/lib/libvirt/images/kdevops/guestfs/nvme_disks/guest-hostname/. if LIBVIRT_STORAGE_POOL_PATH_CUSTOM_MANUAL @@ -1049,13 +1047,13 @@ config LIBVIRT_STORAGE_POOL_PATH_CUSTOM default "/var/lib/libvirt/images" help The path to use for the libvirt storage pool path. Since kdevops uses - Vagrant for virtualization this is also the path used to place the + libvirt for virtualization this is also the path used to place the additional NVMe drives created. kdevops adds a postfix "kdevops" to - this directory as it wants to allow Vagrant full control over that + this directory as it wants to allow libvirt full control over that directory. For instance if this is /var/lib/libvirt/images/ kdevops - will let Vagrant store images in /var/lib/libvirt/images/ and + will let libvirt store images in /var/lib/libvirt/images/ and the NVMe qcow2 files created will go in by default to the directory - /var/lib/libvirt/images/kdevops/.vagrant/nvme_disks/guest-hostname/. + /var/lib/libvirt/images/kdevops/guestfs/nvme_disks/guest-hostname/. endif @@ -1065,7 +1063,7 @@ config LIBVIRT_STORAGE_POOL_CREATE default n if !LIBVIRT_STORAGE_POOL_PATH_INFER_ADVANCED default $(shell, ./scripts/get_libvirsh_pool_enabled.sh) if LIBVIRT_STORAGE_POOL_PATH_INFER_ADVANCED help - By default vagrant assumes your storage pool name is "default" and + By default libvirt assumes your storage pool name is "default" and it expects libvirt to have created this for you. If you want to use a custom pool name and path enable this. This is useful if you want to place guest images on another path other than the diff --git a/kconfigs/Kconfig.pcie_passthrough_libvirt b/kconfigs/Kconfig.pcie_passthrough_libvirt new file mode 100644 index 000000000..b6a47f285 --- /dev/null +++ b/kconfigs/Kconfig.pcie_passthrough_libvirt @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: copyleft-next-0.3.1 + +config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH + bool "Enable libvirt PCIE passthrough support" + default n + help + Enable this if you want to enable PCI-E passthrough onto target + guests. + +if KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH + +choice + prompt "What guest target type to passthrough to" + default KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_FIRST + +config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_FIRST + bool "Onto the first guest" + help + Select this option if you want to passthrough PCI-E devices selected + onto the first guest that kdevops generates on the nodes list. + +config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_SPECIFIC + bool "Onto a specific host name you'll specify" + help + Select this option if you want to passthrough PCI-E devices onto + a guest hostname. This means you have foresight into the future + generated kdevops nodes that will be available and you will manually + specify a target hostname you want to use to pass on the selected + PCI-E devices to. + +config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_EACH + bool "Per device specific host" + help + Select this option if you want to have the option passthrough PCI-E + devices to different target guests. This will allow you to have the + ability to specify for each found PCI-E device which, to which target + guest you want to enable the device to passthrough onto. + +endchoice + +config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TARGET_HOSTNAME + string "Guest target hostname to passthrough PCI-E devices to" + default "enter-valid-hostname" + depends on KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_SPECIFIC + help + Set this to the hostname of the target guest you want to passthrough + the enabled PCI-E devices to. + +menu "Select which PCI-E devices to passthrough" +source "kconfigs/Kconfig.passthrough_libvirt.generated" +endmenu + +endif # KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH diff --git a/kconfigs/workflows/Kconfig.data_partition b/kconfigs/workflows/Kconfig.data_partition index 7a6a592fa..8d0d74a5c 100644 --- a/kconfigs/workflows/Kconfig.data_partition +++ b/kconfigs/workflows/Kconfig.data_partition @@ -55,8 +55,8 @@ config WORKFLOW_INFER_USER_AND_GROUP typically set the username and group ownership of that partition based on passed manual settings. Providing a good guess as defaults through kconfig about what the target user and group should be for the - data partition for systems created with vagrant is easy, but this is - not as easy when users are using Terraform or bare metal. Instead of + data partition for systems created with libvirt is easy, but this is + not as easy when users are using Terraform or bare metal. Instead of extending the possible sensible defaults for the target username and group to use for the data partition based the mechanism used for bringup or Linux distribution chosen, we also provide support to infer @@ -72,7 +72,6 @@ if !WORKFLOW_INFER_USER_AND_GROUP config WORKFLOW_DATA_USER string "The username to use to chown on the target data workflow directory" default "kdevops" if GUESTFS - default "vagrant" if VAGRANT default TERRAFORM_SSH_CONFIG_USER if TERRAFORM help Manual setting for the username to chown the data workflow path. @@ -80,15 +79,13 @@ config WORKFLOW_DATA_USER config WORKFLOW_DATA_GROUP string "The group to use to chown on the target data workflow directory" default "kdevops" if GUESTFS - default "vagrant" if VAGRANT default TERRAFORM_SSH_CONFIG_USER if TERRAFORM_AWS_AMI_DEBIAN || TERRAFORM_AZURE_IMAGE_PUBLISHER_DEBIAN default "users" if !TERRAFORM_AWS_AMI_DEBIAN && !TERRAFORM_AZURE_IMAGE_PUBLISHER_DEBIAN - default "root" if !VAGRANT && !TERRAFORM_AWS_AMI_DEBIAN && !TERRAFORM_AZURE_IMAGE_PUBLISHER_DEBIAN + default "root" if !TERRAFORM_AWS_AMI_DEBIAN && !TERRAFORM_AZURE_IMAGE_PUBLISHER_DEBIAN help Manual setting for the group to chgrp the data workflow path. - We default to "vagrant" if you are using vagrant, otherwise we rely - on the the assumption your distribution has the "users" group created + We rely on the assumption your distribution has the "users" group created for distributions where we are certain of that. If on debian based systems we assume the same group exists with the username you used to log in. diff --git a/playbooks/install_vagrant_boxes.yml b/playbooks/install_vagrant_boxes.yml deleted file mode 100644 index 8cffb36a9..000000000 --- a/playbooks/install_vagrant_boxes.yml +++ /dev/null @@ -1,5 +0,0 @@ ---- -- hosts: localhost - tasks: - - include_role: - name: install_vagrant_boxes diff --git a/playbooks/roles/gen_pci_kconfig/tasks/main.yml b/playbooks/roles/gen_pci_kconfig/tasks/main.yml index fefd3b8be..b491426ff 100644 --- a/playbooks/roles/gen_pci_kconfig/tasks/main.yml +++ b/playbooks/roles/gen_pci_kconfig/tasks/main.yml @@ -5,6 +5,6 @@ - kdevops_pcie_dynamic_kconfig - name: Generate libvirt PCI-E kcofig files - shell: "./python/workflows/dynamic-kconfig/gen-dynamic-pci.py {{ topdir_path }}/.dynamic-kconfig.pci.txt > {{ topdir_path }}/vagrant/Kconfig.passthrough_libvirt.generated" + shell: "./python/workflows/dynamic-kconfig/gen-dynamic-pci.py {{ topdir_path }}/.dynamic-kconfig.pci.txt > {{ topdir_path }}/kconfigs/Kconfig.passthrough_libvirt.generated" when: - kdevops_pcie_dynamic_kconfig diff --git a/playbooks/roles/install_terraform/tasks/install-deps/suse/main.yml b/playbooks/roles/install_terraform/tasks/install-deps/suse/main.yml index 0b24a06ae..39cebe6f6 100644 --- a/playbooks/roles/install_terraform/tasks/install-deps/suse/main.yml +++ b/playbooks/roles/install_terraform/tasks/install-deps/suse/main.yml @@ -30,7 +30,7 @@ - force_install_zip|bool - force_install_if_present|bool or (is_sle or is_leap and terraform_present.rc != 0) -- name: Install vagrant and vagrant-libvirt from your tumbleweed repository +- name: Install terraform from your tumbleweed repository become: yes become_method: sudo ansible.builtin.package: diff --git a/playbooks/roles/install_vagrant_boxes/README.md b/playbooks/roles/install_vagrant_boxes/README.md deleted file mode 100644 index b755febc2..000000000 --- a/playbooks/roles/install_vagrant_boxes/README.md +++ /dev/null @@ -1,46 +0,0 @@ -install-vagrant-boxes -===================== - -The ansible install-vagrant-boxes role lets you get install additional vagrant -boxes which may be outside of the public catalog. - -Requirements ------------- - -Run system using vagrant. - -Role Variables --------------- - - * kdevops_install_vagrant_boxes: set to True to enable installing boxes - * vagrant_boxes: this role is designed so that you override this varaible - your own list of boxes. - -Dependencies ------------- - -None. - -Example Playbook ----------------- - -Below is an example playbook, say a install-vagrant-boxes-sle.yml file which -would try to install the aarch64 vagrant boxes for SLE using some URLs you -have access to: - -``` ---- -- hosts: localhost - tasks: - - include_role: - name: install-vagrant-boxes - vars: - vagrant_boxes: - - { name: 'suse/sle12sp5.aarch64', box_url: 'http://some.com/SLES12-SP5-Vagrant.aarch64-12.5-libvirt_aarch64-GM.vagrant.libvirt.box' } - - { name: 'suse/sle15sp2.aarch64', box_url: 'http://some.com/SLES15-SP2-Vagrant.aarch64-15.2-libvirt_aarch64-Snapshot2.vagrant.libvirt.box' } -``` - -License -------- - -copyleft-next-0.3.1 diff --git a/playbooks/roles/install_vagrant_boxes/defaults/main.yml b/playbooks/roles/install_vagrant_boxes/defaults/main.yml deleted file mode 100644 index 13165a7ce..000000000 --- a/playbooks/roles/install_vagrant_boxes/defaults/main.yml +++ /dev/null @@ -1,6 +0,0 @@ ---- -# Example boxes with URLs. You would override this. -kdevops_install_vagrant_boxes: False -vagrant_boxes: - - { name: 'suse/sle12sp5.x86_64', box_url: 'http://example.com/SLE-12-SP5-Vagrant-GM/SLES12-SP5-Vagrant.x86_64-12.5-libvirt-GM.vagrant.libvirt.box' } - - { name: 'suse/sle15sp2.x86_64', box_url: 'http://example.com/SLES15-SP2-Vagrant.x86_64-15.2-libvirt-Snapshot2.vagrant.libvirt.box' } diff --git a/playbooks/roles/install_vagrant_boxes/scripts/add-box-if-missing.sh b/playbooks/roles/install_vagrant_boxes/scripts/add-box-if-missing.sh deleted file mode 100755 index b14a52f3e..000000000 --- a/playbooks/roles/install_vagrant_boxes/scripts/add-box-if-missing.sh +++ /dev/null @@ -1,48 +0,0 @@ -#!/bin/bash -# Looks to see if a vagrant box is present -# Vagrant lacks the ability to tell you if a box is present in one -# single command line so we have to wrap this up for it. - -TMP_FILE="" - -box_search_finish() -{ - if [[ ! -z $TMP_FILE ]]; then - rm -f $TMP_FILE - fi -} - -trap "box_search_finish" EXIT - -if [[ $# -ne 2 ]]; then - echo "Usage: $0 " - exit 1 -fi - -BOX=$1 -BOX_URL=$2 - -BOX_SEARCH="$1\s\+" -TMP_FILE=$(mktemp) - -vagrant box list > $TMP_FILE -grep -q "$BOX_SEARCH" $TMP_FILE -if [ $? -eq 0 ] ; then - exit 0 -else - NAME_ARGS="" - echo $BOX_URL | grep -q json$ - # Sadly we cannot rename boxes in json format, so we must stick to - # what is given. - if [[ $? -ne 0 ]]; then - NAME_ARGS="--name $BOX" - fi - vagrant box add --provider=libvirt --insecure $NAME_ARGS $BOX_URL - RET=$? - # We use a special return value to indicate change to the - # ansible script, so that it can tell a change has occurred. - if [ $RET -eq 0 ]; then - exit 314 - fi - exit $RET -fi diff --git a/playbooks/roles/install_vagrant_boxes/tasks/main.yml b/playbooks/roles/install_vagrant_boxes/tasks/main.yml deleted file mode 100644 index 430050f5c..000000000 --- a/playbooks/roles/install_vagrant_boxes/tasks/main.yml +++ /dev/null @@ -1,49 +0,0 @@ ---- -- name: Import optional extra_args file - include_vars: "{{ item }}" - ignore_errors: yes - with_first_found: - - files: - - "../extra_vars.yml" - - "../extra_vars.yaml" - - "../extra_vars.json" - skip: true - tags: vars - -- name: Import optional distribution specific variables - include_vars: "{{ item }}" - ignore_errors: yes - with_first_found: - - files: - - "{{ ansible_facts['os_family']|lower }}.yml" - skip: true - tags: vars - -- name: Verify vagrant installation - command: "which vagrant" - register: vagrant_present - changed_when: vagrant_present.rc == 0 - failed_when: vagrant_present.rc != 0 - tags: [ 'vagrant', 'verify' ] - when: - - kdevops_install_vagrant_boxes|bool - -# vagrant has no single command line to check for this so we have to -# wrap it up ourselves, and we only add a box if not present -- name: Add vagrant box if not present - shell: | - set -o pipefail - {{ role_path }}/scripts/add-box-if-missing.sh {{ item.name }} {{ item.box_url }} - args: - executable: /bin/bash - chdir: "{{ role_path }}" - register: box_check - changed_when: box_check.rc == 314 - failed_when: ( box_check.rc not in [ 0, 314, 58 ] ) - with_items: - - "{{ vagrant_boxes }}" - loop_control: - label: "Adding vagrant box {{ item.name }} if not present" - tags: [ 'vagrant', 'box', 'install' ] - when: - - kdevops_install_vagrant_boxes|bool diff --git a/scripts/bringup.Makefile b/scripts/bringup.Makefile index 5a04448e6..764988166 100644 --- a/scripts/bringup.Makefile +++ b/scripts/bringup.Makefile @@ -6,7 +6,6 @@ else stage-2-$(CONFIG_TERRAFORM) += kdevops_terraform_deps stage-2-$(CONFIG_LIBVIRT_INSTALL) += kdevops_install_libvirt stage-2-$(CONFIG_LIBVIRT_CONFIGURE) += kdevops_configure_libvirt -stage-2-$(CONFIG_VAGRANT_INSTALL_PRIVATE_BOXES) += kdevops_vagrant_boxes stage-2-$(CONFIG_LIBVIRT_VERIFY) += kdevops_verify_libvirt_user stage-2-$(CONFIG_LIBVIRT_STORAGE_POOL_CREATE) += kdevops_libvirt_storage_pool_create diff --git a/scripts/bringup_vagrant.sh b/scripts/bringup_vagrant.sh deleted file mode 100755 index 4e163871d..000000000 --- a/scripts/bringup_vagrant.sh +++ /dev/null @@ -1,101 +0,0 @@ -#!/bin/bash -# SPDX-License-Identifier: copyleft-next-0.3.1 - -set -e - -source ${TOPDIR}/.config -source ${TOPDIR}/scripts/lib.sh - -# Convert the version string x.y.z to a canonical 5 or 6-digit form. -# Inspired by ld-version.sh on linux. This is the way. -get_canonical_version() -{ - IFS=. - set -- $1 - - # If the 2nd or 3rd field is missing, fill it with a zero. - # - # The 4th field, if present, is ignored. - # This occurs in development snapshots as in 2.35.1.20201116 - echo $((10000 * $1 + 100 * ${2:-0} + ${3:-0})) -} - -_vagrant_lacks_parallel() -{ - PARALLEL_MISSING="0.7.0" - VAGRANT_LIBVIRT_VERSION="$(vagrant plugin list | sed -e 's|(| |g' | sed -e 's|,| |g' | awk '{print $2}')" - - OLD=$(get_canonical_version $PARALLEL_MISSING) - CURRENT=$(get_canonical_version $VAGRANT_LIBVIRT_VERSION) - if [[ "$CURRENT" -le "$OLD" ]]; then - return 1 - fi - return 0 -} - -vagrant_check_dups() -{ - NEW_POSSIBLE_INSTANCES=$(vagrant status --machine-readable | grep ",state," | awk -F"," '{print $2}') - EXISTING_USER_INSTANCES=$(vagrant global-status | grep -A 200 -e "-----" | grep -v -e "----" | grep -B 200 " " | awk '{print $2}') - for instance in $NEW_POSSIBLE_INSTANCES ; do - INSTANCE_STATE=$(vagrant status --machine-readable | grep ",state," | awk -F",${instance}," '{print $2}' |awk -F"," '{print $2}') - # We're dealing with a new local instance which is not created - # yet. Now we check to see if globally this user doesn't have - # an existing instance already created. - if [[ "$INSTANCE_STATE" == "not_created" ]]; then - INSTANCE_NEW="true" - for old_instance in $EXISTING_USER_INSTANCES; do - # An older instance already exists, complain - if [[ "$instance" == "$old_instance" ]]; then - INSTANCE_NEW="false" - break - fi - done - # At this point we're only dealing with not_created - # instances *and* we know one does not exist in another - # directory for this user. - - kdevops_pool_path="$CONFIG_LIBVIRT_STORAGE_POOL_PATH" - # For libvirt we can do one more global sanity check - if [[ "$CONFIG_LIBVIRT" == "y" ]]; then - possible_image="${kdevops_pool_path}/vagrant_${instance}.img" - if [[ -f $possible_image ]]; then - echo "Image for instance $instance already exists ($possible_image), skippin bringup wipe of spare drives ..." - continue - fi - fi - - # If we don't do this, old spare drives might be - # left over and we'd be using them up again. - spare_drive_instance_dir="${kdevops_pool_path}/kdevops/$instance" - if [[ -d ${spare_drive_instance_dir} ]]; then - echo "Wiping old instance spare drive directory ... $spare_drive_instance_dir" - rm -rf ${kdevops_pool_path}/kdevops/$instance - fi - fi - done -} - -# This is just a workaround for fedora since we have an old vagrant-libvirt -# plugin that doesn't work with parallel -ARG= -if ! _vagrant_lacks_parallel; then - ARG='--no-parallel' -fi -cd vagrant -if [[ "$CONFIG_VAGRANT_BOX_UPDATE_ON_BRINGUP" == "y" ]]; then - if [[ ! -f $(basename "$KDEVOPS_VAGRANT_PROVISIONED") ]]; then - vagrant box update - fi -fi -if [[ "$CONFIG_VAGRANT_VALIDATE_BEFORE_BRINGUP" == "y" ]]; then - vagrant validate - if [[ $? -ne 0 ]]; then - echo "kdevops: Failed to validate Vagrantfile, stopping here" - exit 1 - fi -fi - -vagrant_check_dups - -vagrant up $ARG diff --git a/scripts/check_distro_kconfig.sh b/scripts/check_distro_kconfig.sh deleted file mode 100755 index 00265474e..000000000 --- a/scripts/check_distro_kconfig.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash -# SPDX-License-Identifier: copyleft-next-0.3.1 - -if [ -s "${TOPDIR}/vagrant/Kconfig.$1" ]; then - echo y -else - echo n -fi diff --git a/scripts/check_pciepassthrough_kconfig.sh b/scripts/check_pciepassthrough_kconfig.sh deleted file mode 100755 index d24fc9f39..000000000 --- a/scripts/check_pciepassthrough_kconfig.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash -# SPDX-License-Identifier: copyleft-next-0.3.1 - -if [[ -s "${TOPDIR}/vagrant/Kconfig.$1" ]]; then - echo y -else - echo n -fi diff --git a/scripts/destroy_vagrant.sh b/scripts/destroy_vagrant.sh deleted file mode 100755 index bd5e43d00..000000000 --- a/scripts/destroy_vagrant.sh +++ /dev/null @@ -1,30 +0,0 @@ -#!/bin/bash -# SPDX-License-Identifier: copyleft-next-0.3.1 - -set -e - -source ${TOPDIR}/.config -source ${TOPDIR}/scripts/lib.sh - -cd vagrant -vagrant destroy -f -# Make sure the user can nuke this stuff -sudo chgrp $USER . .vagrant -sudo chmod g+rwx . .vagrant -rm -rf .vagrant - -# These are not initilized instances, our current directory possible -# instances. If you're running 'make destroy' you know what you are -# doing so we don't check for global dups or anything like that. -UNINIT_CURRENT_INSTANCES=$(vagrant status --machine-readable | grep ",state," | grep not_created | awk -F "," '{print $2}') -for i in $UNINIT_CURRENT_INSTANCES; do - UNINIT_INSTANCE_SPARE_DRIVE_DIR="${CONFIG_LIBVIRT_STORAGE_POOL_PATH}/kdevops/$i" - if [[ -d $UNINIT_INSTANCE_SPARE_DRIVE_DIR ]]; then - echo "Found unitialized (possibly old) instance spare drive directory, removing it ... $i" - rm -rf $UNINIT_INSTANCE_SPARE_DRIVE_DIR - fi -done - -if [[ -f $(basename "$KDEVOPS_VAGRANT_PROVISIONED") ]]; then - rm -f $(basename "$KDEVOPS_VAGRANT_PROVISIONED") ]]; -fi diff --git a/scripts/dynamic-pci-kconfig.Makefile b/scripts/dynamic-pci-kconfig.Makefile index 716cdc1e4..2d2f0d5c7 100644 --- a/scripts/dynamic-pci-kconfig.Makefile +++ b/scripts/dynamic-pci-kconfig.Makefile @@ -2,7 +2,7 @@ PCIE_RUNTIME_VARS := "topdir_path": $(TOPDIR_PATH) -KDEVOPS_MRPROPER += vagrant/Kconfig.passthrough_libvirt.generated +KDEVOPS_MRPROPER += kconfigs/Kconfig.passthrough_libvirt.generated ifneq (,$(KDEVOPS_ENABLE_PCIE_KCONFIG)) DYNAMIC_KCONFIG += dynamic_pcipassthrough_kconfig @@ -12,7 +12,7 @@ endif ifeq (,$(KDEVOPS_ENABLE_PCIE_KCONFIG)) DYNAMIC_KCONFIG += dynamic_pcipassthrough_kconfig_touch dynamic_pcipassthrough_kconfig_touch: - $(Q)touch vagrant/Kconfig.passthrough_libvirt.generated + $(Q)touch kconfigs/Kconfig.passthrough_libvirt.generated endif ifeq (y,$(CONFIG_KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH)) diff --git a/scripts/gen-nodes.Makefile b/scripts/gen-nodes.Makefile index 775ec5c49..2642f518d 100644 --- a/scripts/gen-nodes.Makefile +++ b/scripts/gen-nodes.Makefile @@ -4,8 +4,6 @@ GEN_NODES_EXTRA_ARGS += kdevops_nodes='$(KDEVOPS_NODES)' GEN_NODES_EXTRA_ARGS += kdevops_nodes_template='$(KDEVOPS_NODES_TEMPLATE)' GEN_NODES_EXTRA_ARGS += kdevops_nodes_template_full_path='$(TOPDIR_PATH)/$(KDEVOPS_NODES_TEMPLATE)' -GEN_NODES_EXTRA_ARGS += vagrant_box='$(subst ",,$(CONFIG_VAGRANT_BOX))' -GEN_NODES_EXTRA_ARGS += vagrant_box_version='$(subst ",,$(CONFIG_VAGRANT_BOX_VERSION))' GEN_NODES_EXTRA_ARGS += libvirt_vcpus_count='$(subst ",,$(CONFIG_LIBVIRT_VCPUS_COUNT))' GEN_NODES_EXTRA_ARGS += libvirt_mem_mb='$(subst ",,$(CONFIG_LIBVIRT_MEM_MB))' diff --git a/scripts/get-distro-default-bridge.sh b/scripts/get-distro-default-bridge.sh index d1321db5a..c3f68b45c 100755 --- a/scripts/get-distro-default-bridge.sh +++ b/scripts/get-distro-default-bridge.sh @@ -4,9 +4,8 @@ DISTRO=$1 VIRT_TYPE=$2 # We currently ignore the distro because as far as we're concerned -# they all use the default IP, the only thing that differiantes it -# is if you are using vagrant or guestfs. If your distribution needs -# a different deafult it should be easy for you to extend it here. +# they all use the default IP. If your distribution needs a different +# default it should be easy for you to extend it here. DISTRO_FEDORA=`scripts/os-release-check.sh fedora` if [[ "$DISTRO_FEDORA" == "y" ]]; then @@ -14,8 +13,4 @@ if [[ "$DISTRO_FEDORA" == "y" ]]; then exit 0 fi -if [[ "$VIRT_TYPE" == "vagrant" ]]; then - echo "192.168.124.1" -else - echo "192.168.122.1" -fi +echo "192.168.122.1" diff --git a/scripts/provision.Makefile b/scripts/provision.Makefile index 92a754108..f56b2a2de 100644 --- a/scripts/provision.Makefile +++ b/scripts/provision.Makefile @@ -44,7 +44,6 @@ KDEVOPS_DESTROY_DEPS := # We export this into Makefiles so that we can use them both on Makefiles and # on Kconfig files with environment variables such as $(FOO) export KDEVOPS_DEFAULT_DISTRO := $(shell $(TOPDIR)/scripts/get-distro-prefix.sh) -export KDEVOPS_DEFAULT_BRIDGE_IP_VAGRANT := $(shell $(TOPDIR)/scripts/get-distro-default-bridge.sh $(KDEVOPS_DEFAULT_DISTRO) vagrant) export KDEVOPS_DEFAULT_BRIDGE_IP_GUESTFS := $(shell $(TOPDIR)/scripts/get-distro-default-bridge.sh $(KDEVOPS_DEFAULT_DISTRO) guestfs) # These go last @@ -56,9 +55,6 @@ ifeq (y,$(CONFIG_TERRAFORM)) include scripts/terraform.Makefile endif # CONFIG_TERRAFORM -ifeq (y,$(CONFIG_VAGRANT)) -include scripts/vagrant.Makefile -endif ifeq (y,$(CONFIG_GUESTFS)) include scripts/guestfs.Makefile diff --git a/scripts/prune_stale_vagrant.sh b/scripts/prune_stale_vagrant.sh deleted file mode 100755 index 61ac0e86b..000000000 --- a/scripts/prune_stale_vagrant.sh +++ /dev/null @@ -1,164 +0,0 @@ -#!/bin/bash -# SPDX-License-Identifier: copyleft-next-0.3.1 - -set -e - -source .config -source scripts/lib.sh - -SUDO_REQ="sudo" -EVALUATE="false" -THIS_SCRIPT=$0 - -run_prune_path() -{ - EVAL_ARGS="" - if [[ "$1" == "true" ]]; then - EVAL_ARGS="--evaluate" - fi - POOLS=$($SUDO_REQ virsh pool-list | grep -A 2000 -e "---" | grep -v -e "---" | awk '{print $1}') - for p in $POOLS; do - POOL_PATH=$($SUDO_REQ virsh pool-dumpxml $p | grep path | sed -e 's|||' | sed -e 's|||' | awk '{print $1}') - echo "Evaluating pool $p with path $POOL_PATH ..." - $THIS_SCRIPT $EVAL_ARGS $POOL_PATH - if [[ $? -ne 0 ]]; then - echo "Inspect pool $p there is something odd with it or its empty and unused" - fi - done -} - -if [[ "$CONFIG_LIBVIRT_URI_SESSION" == "y" ]]; then - SUDO_REQ="" -fi - -if [[ "$CONFIG_LIBVIRT" != "y" ]]; then - echo "Only libvirt is supported at this time for this prune" - exit 1 -fi - -if [[ $# -eq 0 ]]; then - KDEVOPS_POOL_PATH="$CONFIG_LIBVIRT_STORAGE_POOL_PATH" -elif [[ $# -eq 1 ]]; then - if [[ "$1" == "--help" ]]; then - echo "Usage: $0" - echo " --evaluate -- evaluates how much savings you could on your configured pool" - echo " --evaluate -- evaluates how much savings you could on a specific pool path" - echo " --prune-eval-pools -- evaluates how much savings you could save if we tried to prune all kdevops pools" - echo " --prune-pools -- prunes all pools found for kdevops" - exit - elif [[ "$1" == "--prune-pools" ]]; then - echo unsupported - exit 1 - run_prune_path false - exit - elif [[ "$1" == "--prune-eval-pools" ]]; then - run_prune_path true - exit - else - KDEVOPS_POOL_PATH="$1" - fi -elif [[ $# -eq 2 ]]; then - if [[ "$1" == "--evaluate" ]]; then - EVALUATE="true" - KDEVOPS_POOL_PATH="$2" - else - echo "Usage: $0 --evaluate | $0 | $0 " - exit - fi -else - echo "Usage: $0 --evaluate | $0 | $0 " - exit -fi - -if [[ ! -d $KDEVOPS_POOL_PATH ]]; then - echo "$KDEVOPS_POOL_PATH does not exist, no need to prune, maybe destroy and undefine this pool" - echo "Consider running the following if this is a stale pool:" - echo "$SUDO_REQ virsh pool-destroy " - echo "$SUDO_REQ virsh pool-undefine " - exit 1 -fi - -HOMES=$(cat /etc/passwd| awk -F":" '{print $6}') -for i in $HOMES; do - if [[ "$KDEVOPS_POOL_PATH" == "$i" || "$KDEVOPS_POOL_PATH" == "$i/" ]]; then - echo "Skipping odd pool on a home directory $i" - exit 1 - fi -done - -EXISTING_USAGE=$(du -hs $KDEVOPS_POOL_PATH) -EXISTING_USAGE_BYTES=$(du -s --block-size=1 $KDEVOPS_POOL_PATH | awk '{print $1}') - -echo -e "Existing disk usage:\n$EXISTING_USAGE" - -ALL_LIBVIRT_INSTANCES=$($SUDO_REQ virsh list --all --title | grep -A 200 -e "----" | grep -v -e "---" | awk '{print $2}') - -BYTES_COULD_SAVE=0 - -# Scan the libvirt images with a vagrant prefix images not registered somehow -# to libvirt. This would be odd. We ignore libvirt images not related to -# vagrant. -for i in ${KDEVOPS_POOL_PATH}/vagrant_*.img; do - EXISTS="n" - IMAGE_INSTANCE=$(basename ${i%*.img}) - for INSTANCE in $ALL_LIBVIRT_INSTANCES; do - if [[ "$INSTANCE" == "$IMAGE_INSTANCE" ]]; then - EXISTS="y" - fi - done - if [[ "$EXISTS" == "n" ]]; then - echo "Instance $IMAGE_INSTANCE does not exist and is therefore stale" - if [[ "$EVALUATE" == "true" ]]; then - BYTES=$(du -s --block-size=1 $i | awk '{print $1}') - let BYTES_COULD_SAVE=$BYTES_COULD_SAVE+BYTES - else - rm -rf $i - fi - fi -done - -# Now scan only the spare kdevops drives. Since we're only looking -# at the kdevops directory we are ignoring non-kdevops instances -# data. -for i in ${KDEVOPS_POOL_PATH}/kdevops/*; do - EXISTS="n" - if [[ ! -d $i ]]; then - continue - fi - DIR=$(basename $i) - for INSTANCE in $ALL_LIBVIRT_INSTANCES; do - if [[ "vagrant_${DIR}" == "$INSTANCE" ]]; then - EXISTS="y" - fi - done - if [[ "$EXISTS" == "n" ]]; then - echo "Spare kdevops drive exists without any instance: $DIR" - if [[ "$EVALUATE" == "true" ]]; then - BYTES=$(du -s --block-size=1 $i | awk '{print $1}') - let BYTES_COULD_SAVE=$BYTES_COULD_SAVE+BYTES - else - rm -rf $i - fi - fi -done - - -if [[ "$EVALUATE" == "true" ]]; then - if [[ "$BYTES_COULD_SAVE" == "0" ]]; then - echo "Nothing to prune on $KDEVOPS_POOL_PATH" - else - echo "You could save $BYTES_COULD_SAVE bytes ( $((BYTES_COULD_SAVE/1024/1024)) MiB or $((BYTES_COULD_SAVE/1024/1024/1024)) GiB $((BYTES_COULD_SAVE/1024/1024/1024/1024)) TiB)" - fi -else - AFTER_USAGE_BYTES=$(du -s --block-size=1 $KDEVOPS_POOL_PATH | awk '{print $1}') - DELTA=0 - DELTA=$((EXISTING_USAGE_BYTES-AFTER_USAGE_BYTES)) - - AFTER_USAGE=$(du -hs $KDEVOPS_POOL_PATH) - echo -e "After prune disk usage:\n$AFTER_USAGE" - if [[ $DELTA == "0" ]]; then - echo "No disk savings after prune" - else - echo "Saved $DELTA bytes ( $((DELTA/1024/1024)) MiB or $((DELTA/1024/1024/1024)) GiB $((DELTA/1024/1024/1024/1024)) TiB)" - fi -fi diff --git a/scripts/vagrant.Makefile b/scripts/vagrant.Makefile deleted file mode 100644 index e43a21d3c..000000000 --- a/scripts/vagrant.Makefile +++ /dev/null @@ -1,109 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 - -VAGRANT_ARGS := - -KDEVOPS_NODES_TEMPLATE := $(KDEVOPS_NODES_ROLE_TEMPLATE_DIR)/kdevops_nodes_split_start.j2.yaml -KDEVOPS_NODES := vagrant/kdevops_nodes.yaml - -KDEVOPS_VAGRANT_TEMPLATE := $(KDEVOPS_NODES_ROLE_TEMPLATE_DIR)/Vagrantfile.j2 -KDEVOPS_VAGRANT_GENERATED:= vagrant/.Vagrantfile.generated -KDEVOPS_VAGRANT := vagrant/Vagrantfile - -export KDEVOPS_PROVISIONED_SSH := $(KDEVOPS_PROVISIONED_SSH_DEFAULT_GUARD) - -KDEVOPS_MRPROPER += $(KDEVOPS_VAGRANT_GENERATED) -KDEVOPS_MRPROPER += $(KDEVOPS_VAGRANT) - -VAGRANT_ARGS += kdevops_vagrant_template_full_path='$(TOPDIR_PATH)/$(KDEVOPS_VAGRANT_TEMPLATE)' - -VAGRANT_ARGS += kdevops_enable_vagrant=True -VAGRANT_ARGS += kdevops_vagrant='$(KDEVOPS_VAGRANT)' -VAGRANT_ARGS += kdevops_vagrant_generated='$(KDEVOPS_VAGRANT_GENERATED)' -VAGRANT_ARGS += kdevops_vagrant_template='$(KDEVOPS_VAGRANT_TEMPLATE)' - -VAGRANT_ARGS += data_user='vagrant' -VAGRANT_ARGS += data_vagrant='vagrant' - -ifeq (y,$(CONFIG_HAVE_VAGRANT_BOX_URL)) -VAGRANT_PRIVATE_BOX_DEPS := vagrant_private_box_install -else -VAGRANT_PRIVATE_BOX_DEPS := -endif - -ifeq (y,$(CONFIG_LIBVIRT)) -VAGRANT_ARGS += libvirt_provider=True - -QEMU_GROUP:=$(subst ",,$(CONFIG_LIBVIRT_QEMU_GROUP)) -VAGRANT_ARGS += kdevops_storage_pool_group='$(QEMU_GROUP)' -VAGRANT_ARGS += storage_pool_group='$(QEMU_GROUP)' -endif - -ifeq (y,$(CONFIG_VAGRANT_VIRTUALBOX)) -VAGRANT_ARGS += virtualbox_provider=True -endif - -VAGRANT_9P_HOST_CLONE := -ifeq (y,$(CONFIG_BOOTLINUX_9P)) -VAGRANT_9P_HOST_CLONE := vagrant_9p_linux_clone -endif - -LIBVIRT_PCIE_PASSTHROUGH := -ifeq (y,$(CONFIG_KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH)) -LIBVIRT_PCIE_PASSTHROUGH := libvirt_pcie_passthrough_permissions -endif - -ifneq ($(strip $(CONFIG_RHEL_ORG_ID)),) -ifneq ($(strip $(CONFIG_RHEL_ACTIVATION_KEY)),) -RHEL_ORG_ID:=$(subst ",,$(CONFIG_RHEL_ORG_ID)) -RHEL_ACTIVATION_KEY:=$(subst ",,$(CONFIG_RHEL_ACTIVATION_KEY)) -VAGRANT_ARGS += rhel_org_id="$(RHEL_ORG_ID)" -VAGRANT_ARGS += rhel_activation_key="$(RHEL_ACTIVATION_KEY)" -endif -endif - -EXTRA_VAR_INPUTS += extend-extra-args-vagrant -ANSIBLE_EXTRA_ARGS += $(VAGRANT_ARGS) - -VAGRANT_BRINGUP_DEPS := -VAGRANT_BRINGUP_DEPS += $(VAGRANT_PRIVATE_BOX_DEPS) -VAGRANT_BRINGUP_DEPS += $(VAGRANT_9P_HOST_CLONE) -VAGRANT_BRINGUP_DEPS += $(LIBVIRT_PCIE_PASSTHROUGH) - -KDEVOPS_PROVISION_METHOD := bringup_vagrant -KDEVOPS_PROVISION_DESTROY_METHOD := destroy_vagrant - -extend-extra-args-vagrant: - @if [[ "$(CONFIG_HAVE_VAGRANT_BOX_URL)" == "y" ]]; then \ - echo "kdevops_install_vagrant_boxes: True" >> $(KDEVOPS_EXTRA_VARS) ;\ - echo "vagrant_boxes:" >> $(KDEVOPS_EXTRA_VARS) ;\ - echo " - { name: '$(CONFIG_VAGRANT_BOX)', box_url: '$(CONFIG_VAGRANT_BOX_URL)' }" >> $(KDEVOPS_EXTRA_VARS) ;\ - fi - -vagrant_private_box_install: - $(Q)ansible-playbook $(ANSIBLE_VERBOSE) -i \ - $(KDEVOPS_HOSTFILE) $(KDEVOPS_PLAYBOOKS_DIR)/install_vagrant_boxes.yml - -vagrant_9p_linux_clone: - $(Q)make linux-clone - -libvirt_pcie_passthrough_permissions: - $(Q)ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ - --inventory localhost, \ - playbooks/libvirt_pcie_passthrough.yml - -$(KDEVOPS_PROVISIONED_SSH): - $(Q)if [[ "$(CONFIG_KDEVOPS_SSH_CONFIG_UPDATE)" == "y" ]]; then \ - ansible-playbook $(ANSIBLE_VERBOSE) --connection=local \ - --inventory localhost, \ - playbooks/update_ssh_config_vagrant.yml - fi - $(Q)touch $(KDEVOPS_PROVISIONED_SSH) - -bringup_vagrant: $(VAGRANT_BRINGUP_DEPS) - $(Q)$(TOPDIR)/scripts/bringup_vagrant.sh -PHONY += bringup_vagrant - -destroy_vagrant: - $(Q)$(TOPDIR)/scripts/destroy_vagrant.sh - $(Q)rm -f $(KDEVOPS_PROVISIONED_SSH) - $(Q)rm -f $(KDEVOPS_PROVISIONED_SSH) $(KDEVOPS_PROVISIONED_DEVCONFIG) diff --git a/scripts/workflows/generic/run_kernel_ci.sh b/scripts/workflows/generic/run_kernel_ci.sh index 2bf14278e..57c084252 100755 --- a/scripts/workflows/generic/run_kernel_ci.sh +++ b/scripts/workflows/generic/run_kernel_ci.sh @@ -237,19 +237,13 @@ kernel_ci_watchdog_loop() grep runtime $KERNEL_CI_WATCHDOG_RESULTS >> $KERNEL_CI_WATCHDOG_FAIL_LOG cat $KERNEL_CI_WATCHDOG_TIMEOUT >> $KERNEL_CI_WATCHDOG_FAIL_LOG fi - if [[ "$WATCHDOG_RESET_HUNG_SYSTEMS" == "y" ]]; then - for i in $(awk '{print $1}' $KERNEL_CI_WATCHDOG_RESULTS | grep -E -v "runtime|Hostname"); do - if [[ "$CONFIG_VAGRANT" == "y" ]]; then - sudo virsh reset vagrant_$i - elif [[ "$CONFIG_GUESTFS" == "y" ]]; then - sudo virsh reset $i - else - echo "$i : Unsupported crashy reset for this bringup configuration" >> $KERNEL_CI_WATCHDOG_FAIL_LOG - fi - echo -e "\nReset all your associated systems:" >> $KERNEL_CI_WATCHDOG_FAIL_LOG - echo -e "\t$i" >> $KERNEL_CI_WATCHDOG_FAIL_LOG - done - fi + if [[ "$WATCHDOG_RESET_HUNG_SYSTEMS" == "y" ]]; then + for i in $(awk '{print $1}' $KERNEL_CI_WATCHDOG_RESULTS | grep -E -v "runtime|Hostname"); do + sudo virsh reset $i + echo -e "\nReset all your associated systems:" >> $KERNEL_CI_WATCHDOG_FAIL_LOG + echo -e "\t$i" >> $KERNEL_CI_WATCHDOG_FAIL_LOG + done + fi break fi fi diff --git a/terraform/azure/main.tf b/terraform/azure/main.tf index 7a91a8699..2da47d325 100644 --- a/terraform/azure/main.tf +++ b/terraform/azure/main.tf @@ -93,7 +93,7 @@ resource "azurerm_linux_virtual_machine" "kdevops_vm" { count = local.kdevops_num_boxes # As of terraform 0.11 there is no easy way to convert a list to a map - # for the structure we have defined for the vagrant_boxes. We can use + # for the structure we have defined for the guest list. We can use # split to construct a subjset list though, and then key in with the # target left hand value name we want to look for. On the last split we # call always uses the second element given its a value: figure, we want diff --git a/vagrant/.gitignore b/vagrant/.gitignore deleted file mode 100644 index 2a00270b0..000000000 --- a/vagrant/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -.vagrant -*.img diff --git a/vagrant/Kconfig b/vagrant/Kconfig deleted file mode 100644 index ecf7bcafe..000000000 --- a/vagrant/Kconfig +++ /dev/null @@ -1,295 +0,0 @@ -if VAGRANT - -choice - prompt "Vagrant virtualization technology to use" - default VAGRANT_LIBVIRT_SELECT - -config VAGRANT_LIBVIRT_SELECT - bool "Libvirt" - help - Select this option if you want to use KVM / libvirt for - local virtualization. - -config VAGRANT_VIRTUALBOX - bool "Virtualbox" - select EXTRA_STORAGE_SUPPORTS_512 - select EXTRA_STORAGE_SUPPORTS_1K - select EXTRA_STORAGE_SUPPORTS_2K - select EXTRA_STORAGE_SUPPORTS_4K - help - Select this option if you want to use VirtualBox for - local virtualization. - -endchoice - -if VAGRANT_VIRTUALBOX - -choice - prompt "VirtualBox storage pool path" - default VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_MANUAL if !DISTRO_SUSE - default VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_CWD if DISTRO_SUSE - -config VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_CWD - bool "Use the current vagrant working directory" - help - Select this option if you want to use the vagrant directory inside - where you git cloned kdevops as the Vagrant storage pool path where - additional NVMe drives will be created. As it is today it - would seem only fedora restricts the $HOME to g-rwx o-rwx and so - by default this option won't work on Fedora by default. This used - to be the old default on kdevops but because of this it should not - be used by default. Distributions still relying on this should - verify they can change this default. - -config VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_MANUAL - bool "Custom manual path" - help - Select this option if you want to manually specify where to use as - the directory where we'll have kdevops create additional NVMe drives - for VirtualBox to use. This is today's default given otherwise - we may have to muck with the $HOME directory permissions. - -endchoice - -config VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM - string "VirtualBox storage pool path" - default $(shell, scripts/cwd-append.sh vagrant) if VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_CWD - default "/opt/virtualbox/storage/" if VIRTUALBOX_STORAGE_POOL_PATH_CUSTOM_MANUAL - help - The path to use for creating additional NVMe drives used by - VirtualBox. kdevops adds a postfix "kdevops" to this directory as it - wants to allow Vagrant full control over that directory. For instance - if this is /opt/virtualbox/storage/ kdevops will have VirtualBox - create the NVMe files under the directory - /opt/virtualbox/storage/kdevops/.vagrant/nvme_disks/guest-hostname/. - -choice - prompt "VirtualBox extra drive format" - default VIRTUALBOX_EXTRA_DRIVE_VDI - -config VIRTUALBOX_EXTRA_DRIVE_VDI - bool "vdi" - help - Select this option if you want to use the vdi format. - -config VIRTUALBOX_EXTRA_DRIVE_VMDK - bool "vmdk" - help - Select this option if you want to use the vmdk format. - -config VIRTUALBOX_EXTRA_DRIVE_VHD - bool "vhd" - help - Select this option if you want to use the vhd format. - -endchoice - -config VIRTUALBOX_EXTRA_DRIVE_FORMAT - string - default "vdi" if VIRTUALBOX_EXTRA_DRIVE_VDI - default "vmdk" if VIRTUALBOX_EXTRA_DRIVE_VMDK - default "vhd" if VIRTUALBOX_EXTRA_DRIVE_VHD - -endif # VAGRANT_VIRTUALBOX - -config HAVE_SUSE_VAGRANT - bool - default $(shell, scripts/check_distro_kconfig.sh suse) - -choice - prompt "Vagrant guest Linux distribution to use" - default VAGRANT_DEBIAN if DISTRO_DEBIAN || DISTRO_UBUNTU - default VAGRANT_FEDORA if DISTRO_FEDORA - default VAGRANT_OPENSUSE if DISTRO_OPENSUSE - default VAGRANT_SUSE if HAVE_SUSE_VAGRANT - -config VAGRANT_DEBIAN - bool "Debian" - select HAVE_CUSTOM_DISTRO_HOST_PREFIX - select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS - select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS - select HAVE_DISTRO_EXT4_PREFERS_MANUAL if FSTESTS_EXT4 - select HAVE_DISTRO_PREFERS_CUSTOM_HOST_PREFIX - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - help - This option will set the target guest to Debian. - -config VAGRANT_OPENSUSE - bool "OpenSUSE" - select HAVE_CUSTOM_DISTRO_HOST_PREFIX - select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS - select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS - select HAVE_DISTRO_EXT4_PREFERS_MANUAL if FSTESTS_EXT4 - select HAVE_DISTRO_BLKTESTS_PREFERS_MANUAL if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_CUSTOM_HOST_PREFIX - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - help - This option will set the target guest to OpenSUSE. - -config VAGRANT_SUSE - bool "SUSE" - depends on HAVE_SUSE_VAGRANT - select HAVE_KDEVOPS_CUSTOM_DEFAULTS - select HAVE_CUSTOM_DISTRO_HOST_PREFIX - select HAVE_DISTRO_PREFERS_CUSTOM_HOST_PREFIX - select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS - select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS - select HAVE_DISTRO_BLKTESTS_PREFERS_MANUAL if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_SUSE - select HAVE_DISTRO_PREFERS_REGISTRATION - select HAVE_DISTRO_REG_METHOD_TWOLINE - select VAGRANT_INSTALL_PRIVATE_BOXES - select HAVE_CUSTOM_KDEVOPS_GIT - select HAVE_CUSTOM_KDEVOPS_GIT_DATA - select HAVE_CUSTOM_KDEVOPS_DIR - help - This option will set the target guest to SUSE. There is currently - no scriptable way to download Vagrant images, however the images - are available for download via: - - https://suse.com/download - -config VAGRANT_FEDORA - bool "Fedora (or derived distro)" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS - select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS - select HAVE_DISTRO_EXT4_PREFERS_MANUAL if FSTESTS_EXT4 - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - help - This option will set the target guest to be a distro in the Fedora family. - For example, Fedora, CentOS Stream, RHEL, etc. - -config VAGRANT_KDEVOPS - bool "kdevops kernel builds" - select HAVE_CUSTOM_DISTRO_HOST_PREFIX - select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS - select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS - select HAVE_DISTRO_EXT4_PREFERS_MANUAL if FSTESTS_EXT4 - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_FSTESTS - help - This option will let you select custom kernel builds by the - kdevops project. The distributions may vary and are are specified. -endchoice - -config HAVE_VAGRANT_BOX_VERSION - bool - default n - -source "vagrant/Kconfig.debian" -source "vagrant/Kconfig.opensuse" -source "vagrant/Kconfig.fedora" -source "vagrant/Kconfig.kdevops" - -if HAVE_SUSE_VAGRANT -source "vagrant/Kconfig.suse" -endif # HAVE_SUSE_VAGRANT - -config VAGRANT_BOX - string - default "debian/testing64" if VAGRANT_DEBIAN_TESTING64 || !VAGRANT - default "debian/bullseye64" if VAGRANT_DEBIAN_BULLSEYE64 - default "debian/buster64" if VAGRANT_DEBIAN_BUSTER64 - default "opensuse/Tumbleweed.x86_64" if VAGRANT_OPENSUSE_X86_64_TW - default VAGRANT_FEDORA_BOX_STRING if VAGRANT_FEDORA - default "generic/rhel8" if VAGRANT_REDHAT_GENERIC_RHEL8_X86_64 - default "generic/rhel9" if VAGRANT_REDHAT_GENERIC_RHEL9_X86_64 - default "opensuse/Leap-15.3.x86_64" if VAGRANT_OPENSUSE_X86_64_LEAP_15_3 - default "opensuse/Leap-15.4.x86_64" if VAGRANT_OPENSUSE_X86_64_LEAP_15_4 - default "Leap-15.4.x86_64" if VAGRANT_OPENSUSE_X86_64_LEAP_15_4 - default "linux-kdevops/debian-next-20220629" if VAGRANT_KDEVOPS_DEBIAN_TESTING64_NEXT_20220629 || !VAGRANT - default "linux-kdevops/debian-xfs-20230427" if VAGRANT_KDEVOPS_DEBIAN_TESTING64_XFS_20230427 || !VAGRANT - default VAGRANT_SUSE_BOX if VAGRANT_SUSE - help - The Vagrant box to use. - -config VAGRANT_BOX_UPDATE_ON_BRINGUP - bool "Run Vagrant box update prior to bringup" - default y - help - When you use Vagrant on a system the target box for the distribution - will first be downloaded on its first use. It will not be updated - until you manually run "vagrant box update" on the respective vagrant - directory. This can mean that if your system first used kdevops in - January 2022 and you are using Debian testing, the old version of - Debian testing as of January 2022 will be used if you try to - instantiate a guest in January 2023. This can means your userspace - may be too old to deal with some new kernel features. An example - is zstd module support for initframfs does not work well with old - userspace on Debian testing. The boot will fail when trying to - run "make linux" and it would not be clear why, the reason would be - a failed ext4 module could not be loaded, in fact no modules could - be loaded by the initramfs. To fix the user experience we ensure we - always run "vagrant box update" as the first step to "make bringup". - - Folks testing stable kernels will use stable distributions, such as - Debian bullseye that don't move userspace as often but in fact welcome - their own stable updates to userspace, and this is why this is kept - as enabled by default. - - You may want to disable this if you don't want to deal with these - updates on bringup, and you want to do the updates on your own. - Note that if you already ran bringup with an old box, you won't - reap benefits of the new one until you "make destroy" and then - "make bringup" again. If you are already on an old box and don't - want to destroy your current box image you can just upgrade userspace - manually by the typical distro means to update itself. For example - on Debian testing that's "apt-get update && apt-get dist-upgrade". - -config VAGRANT_VALIDATE_BEFORE_BRINGUP - bool "Validate Vagrantfile prior to bringup" - default y - help - Folks hacking on the Vagrantfile may want to ensure they validate - the Vagrantfile first. This will allow developers to identify issues - prior to running some real virtualization commands. Enable this by - default as validation is fast and safe. - -config VAGRANT_PREFERRED_KERNEL_CI_SUBJECT_TOPIC - string - default VAGRANT_BOX if VAGRANT_DEBIAN_BUSTER64 - default VAGRANT_BOX if VAGRANT_DEBIAN_BULLSEYE64 - -config HAVE_VAGRANT_BOX_URL - bool - -if HAVE_VAGRANT_BOX_URL - -config VAGRANT_BOX_URL - string - depends on HAVE_VAGRANT_BOX_URL - default VAGRANT_SUSE_BOX_URL if HAVE_SUSE_VAGRANT - default "https://download.opensuse.org/repositories/Virtualization:/Appliances:/Images:/openSUSE-Leap-15.4/images/boxes/Leap-15.4.x86_64.json" if VAGRANT_OPENSUSE_X86_64_LEAP_15_4 - -endif # HAVE_VAGRANT_BOX_URL - -if HAVE_VAGRANT_BOX_VERSION - -config VAGRANT_BOX_VERSION - string - default "1.0.20230425" if VAGRANT_OPENSUSE_X86_64_TW_1020230425 - default "1.0.20220528" if VAGRANT_OPENSUSE_X86_64_TW_1020220528 - default "1.0.20210915" if VAGRANT_OPENSUSE_X86_64_TW_1020210915 - default "1.0.20210203" if VAGRANT_OPENSUSE_X86_64_TW_1020210203 - default "1.0.20200714" if VAGRANT_OPENSUSE_X86_64_TW_1020200714 - default "1.0.20210203" if VAGRANT_OPENSUSE_X86_64_TW_1020210203 - default "0.1.0" if VAGRANT_KDEVOPS_DEBIAN_TESTING64_NEXT_20220629 - help - The Vagrant box version to use. This is set for you depending on the - image you select. You can manually override the version we have last - tested here. - -endif # HAVE_VAGRANT_BOX_VERSION - -if !HAVE_VAGRANT_BOX_VERSION - -config VAGRANT_BOX_VERSION - string - default "" - -endif # !HAVE_VAGRANT_BOX_VERSION -endif # VAGRANT diff --git a/vagrant/Kconfig.debian b/vagrant/Kconfig.debian deleted file mode 100644 index c316e728e..000000000 --- a/vagrant/Kconfig.debian +++ /dev/null @@ -1,46 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 -if VAGRANT_DEBIAN - -choice - prompt "Debian release to use" - default VAGRANT_DEBIAN_TESTING64 - -config VAGRANT_DEBIAN_BUSTER64 - bool "debian/buster64" - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - depends on TARGET_ARCH_X86_64 - help - This option will set the target guest to debian/buster64. - -config VAGRANT_DEBIAN_BULLSEYE64 - bool "debian/bullseye64" - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - depends on TARGET_ARCH_X86_64 - help - This option will set the target guest to debian/bullseye64. - -config VAGRANT_DEBIAN_TESTING64 - bool "debian/testing64" - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - depends on TARGET_ARCH_X86_64 - help - This option will set the target guest to debian/testing64. - -endchoice - -config VAGRANT_DEBIAN_BOX_SHORT - string - default "buster64" if VAGRANT_DEBIAN_BUSTER64 - default "bullseye64" if VAGRANT_DEBIAN_BULLSEYE64 - default "testing64" if VAGRANT_DEBIAN_TESTING64 - -endif # VAGRANT_DEBIAN diff --git a/vagrant/Kconfig.fedora b/vagrant/Kconfig.fedora deleted file mode 100644 index 420e6cc81..000000000 --- a/vagrant/Kconfig.fedora +++ /dev/null @@ -1,29 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 -if VAGRANT_FEDORA - -config VAGRANT_FEDORA_BOX_STRING - string "Vagrant box string" - default "fedora/38-cloud-base" - help - This is the box string that vagrant should use. This is typically - something like fedora/??-cloud-base or generic/rhel?. We default - to the latest Fedora cloud-base release. - -config VAGRANT_FEDORA_OLD_RELEASE - bool "Is this an old release (pre-Fedora 32)?" - default n - help - XFS on older Fedora releases lacked support for certain - features. Enabling this will disable testing certain - configurations by default in the fstests workflow. - -config VAGRANT_FEDORA_NEW_RELEASE - bool - default y - depends on !VAGRANT_FEDORA_OLD_RELEASE - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - -endif # VAGRANT_FEDORA diff --git a/vagrant/Kconfig.kdevops b/vagrant/Kconfig.kdevops deleted file mode 100644 index 25398034b..000000000 --- a/vagrant/Kconfig.kdevops +++ /dev/null @@ -1,42 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 -if VAGRANT_KDEVOPS - -choice - prompt "Kdevops release to use" - default VAGRANT_KDEVOPS_DEBIAN_TESTING64_XFS_20230427 - -config VAGRANT_KDEVOPS_DEBIAN_TESTING64_XFS_20230427 - bool "linux-kdevops/debian-xfs-20230427" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - select HAVE_SUPPORTS_PURE_IOMAP - depends on TARGET_ARCH_X86_64 - help - This option will set the target guest to - linux-kdevops/debian-xfs-20230423 which is based on - debian-testing and only uses XFS for the root fs. - -config VAGRANT_KDEVOPS_DEBIAN_TESTING64_NEXT_20220629 - bool "linux-kdevops/debian-next-20220629" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - depends on TARGET_ARCH_X86_64 - help - This option will set the target guest to - linux-kdevops/debian-next-20220629 which is based on - debian-testing. It just has linux-next next-20220629. - -endchoice - -config VAGRANT_DEBIAN_BOX_SHORT - string - default "debian-next-20220629" if VAGRANT_KDEVOPS_DEBIAN_TESTING64_NEXT_20220629 - default "debian-xfs-20230427" if VAGRANT_KDEVOPS_DEBIAN_TESTING64_XFS_20230427 - -endif # VAGRANT_KDEVOPS diff --git a/vagrant/Kconfig.opensuse b/vagrant/Kconfig.opensuse deleted file mode 100644 index 6da402755..000000000 --- a/vagrant/Kconfig.opensuse +++ /dev/null @@ -1,144 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 -if VAGRANT_OPENSUSE - -choice - prompt "OpenSUSE release to use" - default VAGRANT_OPENSUSE_X86_64_LEAP_15_3 - -config VAGRANT_OPENSUSE_X86_64_TW - bool "opensuse/Tumbleweed.x86_64" - depends on TARGET_ARCH_X86_64 - help - Enable this to be able to select between the supported OpenSUSE - Tumbleweed releases. - -config VAGRANT_OPENSUSE_X86_64_LEAP_15_4 - bool "opensuse/Leap-15.4.x86_64" - depends on TARGET_ARCH_X86_64 - select HAVE_DISTRO_BTRFS_DISABLES_RAID56 if FSTESTS_BTRFS - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL - select HAVE_DISTRO_BLKTESTS_TEST_BLOCK if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_BLKTESTS_TEST_LOOP if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_BLKTESTS_TEST_NBD if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_BLKTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_BLKTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_REFRESH - select HAVE_DISTRO_PREFERS_UPDATE - select HAVE_DISTRO_PREFERS_INSTALL_KDEVTOOLS - select HAVE_DISTRO_PREFERS_ANSIBLE_PYTHON2 if !HAVE_DISTRO_PREFERS_DISABLE_ANSIBLE && KDEVOPS_ANSIBLE_PROVISION_ENABLE - help - This enables the OpenSUSE Leap 15.4 release. - -config VAGRANT_OPENSUSE_X86_64_LEAP_15_3 - bool "opensuse/Leap-15.3.x86_64" - depends on TARGET_ARCH_X86_64 - select HAVE_DISTRO_BTRFS_DISABLES_RAID56 if FSTESTS_BTRFS - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG - select HAVE_DISTRO_PREFERS_FSTESTS_WATCHDOG_KILL - select HAVE_DISTRO_BLKTESTS_TEST_BLOCK if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_BLKTESTS_TEST_LOOP if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_BLKTESTS_TEST_NBD if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_BLKTESTS_WATCHDOG if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_BLKTESTS_WATCHDOG_KILL if KDEVOPS_WORKFLOW_ENABLE_BLKTESTS - select HAVE_DISTRO_PREFERS_REFRESH - select HAVE_DISTRO_PREFERS_UPDATE - select HAVE_DISTRO_PREFERS_INSTALL_KDEVTOOLS - select HAVE_DISTRO_PREFERS_ANSIBLE_PYTHON2 if !HAVE_DISTRO_PREFERS_DISABLE_ANSIBLE && KDEVOPS_ANSIBLE_PROVISION_ENABLE - help - This enables the OpenSUSE Leap 15.3 release. - -endchoice - -if VAGRANT_OPENSUSE_X86_64_TW - -choice - prompt "opensuse/Tumbleweed.x86_64 version to use" - default VAGRANT_OPENSUSE_X86_64_TW_1020230529 - -config VAGRANT_OPENSUSE_X86_64_TW_1020230529 - bool "opensuse/Tumbleweed.x86_64 1.0.20230529" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20230529. - - -config VAGRANT_OPENSUSE_X86_64_TW_1020230425 - bool "opensuse/Tumbleweed.x86_64 1.0.20230425" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20230425. - -config VAGRANT_OPENSUSE_X86_64_TW_1020220528 - bool "opensuse/Tumbleweed.x86_64 1.0.20220528" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20220528. - -config VAGRANT_OPENSUSE_X86_64_TW_1020210915 - bool "opensuse/Tumbleweed.x86_64 1.0.20210915 " - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20210915. - -config VAGRANT_OPENSUSE_X86_64_TW_1020210203 - bool "opensuse/Tumbleweed.x86_64 1.0.20210203 " - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20210203. - -config VAGRANT_OPENSUSE_X86_64_TW_1020200714 - bool "opensuse/Tumbleweed.x86_64 1.0.20200714" - select HAVE_VAGRANT_BOX_VERSION - select HAVE_DISTRO_XFS_SUPPORTS_CRC if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_EXTERNAL_LOG if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_REFLINKS if FSTESTS_XFS - select HAVE_DISTRO_XFS_SUPPORTS_BIGBLOCKS if FSTESTS_XFS - help - This option will set the target guest to opensuse/Tumbleweed.x86_64 - release 1.0.20200714. - -endchoice - -endif # VAGRANT_OPENSUSE_X86_64_TW - -config VAGRANT_OPENSUSE_BOX_SHORT - string - default "tw" if VAGRANT_OPENSUSE_X86_64_TW - default "leap15sp3" if VAGRANT_OPENSUSE_X86_64_LEAP_15_3 - default "leap15sp4" if VAGRANT_OPENSUSE_X86_64_LEAP_15_4 - -endif # VAGRANT_OPENSUSE diff --git a/vagrant/Kconfig.pcie_passthrough_libvirt b/vagrant/Kconfig.pcie_passthrough_libvirt deleted file mode 100644 index 62d3a86d4..000000000 --- a/vagrant/Kconfig.pcie_passthrough_libvirt +++ /dev/null @@ -1,53 +0,0 @@ -# SPDX-License-Identifier: copyleft-next-0.3.1 - -config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH - bool "Enable libvirt PCIE passthrough support" - default n - help - Enable this if you want to enable PCI-E passthrough onto target - guests. - -if KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH - -choice - prompt "What guest target type to passthrough to" - default KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_FIRST - -config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_FIRST - bool "Onto the first guest" - help - Select this option if you want to passthrough PCI-E devices selected - onto the first guest that kdevops generates on the nodes list. - -config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_SPECIFIC - bool "Onto a specific host name you'll specify" - help - Select this option if you want to passthrough PCI-E devices onto - a guest hostname. This means you have foresight into the future - generated kdevops nodes that will be available and you will manually - specify a target hostname you want to use to pass on the selected - PCI-E devices to. - -config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_EACH - bool "Per device specific host" - help - Select this option if you want to have the option passthrough PCI-E - devices to different target guests. This will allow you to have the - ability to specify for each found PCI-E device which, to which target - guest you want to enable the device to passthrough onto. - -endchoice - -config KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TARGET_HOSTNAME - string "Guest target hostname to passthrough PCI-E devices to" - default "enter-valid-hostname" - depends on KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH_TYPE_SPECIFIC - help - Set this to the hostname of the target guest you want to passthrough - the enabled PCI-E devices to. - -menu "Select which PCI-E devices to passthrough" -source "vagrant/Kconfig.passthrough_libvirt.generated" -endmenu - -endif # KDEVOPS_LIBVIRT_PCIE_PASSTHROUGH diff --git a/vagrant/Kconfig.suse b/vagrant/Kconfig.suse deleted file mode 100644 index e69de29bb..000000000 diff --git a/workflows/blktests/Kconfig b/workflows/blktests/Kconfig index 6fea67718..d016c4329 100644 --- a/workflows/blktests/Kconfig +++ b/workflows/blktests/Kconfig @@ -131,10 +131,8 @@ config BLKTESTS_WATCHDOG_RESET_HUNG_SYSTEMS have to also implement a way to try to capture kernel logs before a reset. - We currently only enable this for Vagrant provisioning, given we have - to figure out a unified way to express a reset for cloud solution and - also figure out a way to enable this for bare metal. For vagrant we - currently use 'virsh reset' and so this works only if on libvirt. + We currently rely on 'virsh reset' for libvirt based setups. Support + for cloud solutions or bare metal can be extended later as needed. endif # BLKTESTS_WATCHDOG