Project maintainers needed

[electrofelix]

I've been putting this off for a while now as I keep hoping to get back to maintaining this project. The sad reality is that I'm no longer working with it, nor have a system where I could run https://github.com/vagrant-libvirt/vagrant-libvirt-qa to bring it up to date to catch various issues.

So this is a call out for others to help maintain this project and if you have the time, make it easier for others to help out in a smaller capacity by improving the tests, being able to have some of the free CI tooling take care of running through running vagrant-libvirt on multiple OSs as set up in https://github.com/vagrant-libvirt/vagrant-libvirt-qa, either by rewriting it to use a matrix in Travis or something else to exercise the installation of this plugin.

[nilsmeyer]

I would be willing to provide a server for running tests or perhaps set something up at Packet (bare metal on-demand) - at least for qemu/KVM. I should also be able to setup Travis Unfortunately I'm not very good with Ruby so I can't really offer help otherwise.

[tureba]

I've been using this software more and more over the past year. I'll gladly contribute back any way I can. I'll see about running the qa tests and helping out with bugs over the next few days to weeks.

[electrofelix]

I think the major issue is the burden of confirming that changes don't have negative impact, so if there is a way to have the https://github.com/vagrant-libvirt/vagrant-libvirt-qa suite so it could be triggered on demand to test specific PRs as well as master on each merge without someone needing to be able to perform the suite of tests locally that would help enormously

[dustymabe]

CentOS CI also exists for upstream projects to be able to do testing on bare metal nodes. The bare metal usually runs on CentOS nodes but then you can run any OS you want in a VM (nested virt). Might be something to investigate: https://wiki.centos.org/QaWiki/CI/GettingStarted

[hswong3i]

@electrofelix Travis CI now with vmx CPU flag so support Vagrant + Libvirt + KVM, we may no longer required for a self-hosted QA.

See my example from molecule-vagrant:

• BUG: Missing create.yml, destroy.yml, molecule_vagrant.py ansible-community/molecule-vagrant#8 (comment)
• https://github.com/alvistack/ansible-role-virtualbox/blob/71ece443911739388fa16b4374b54004625c925b/.travis.yml
• https://travis-ci.com/github/alvistack/ansible-role-virtualbox/builds/156292261

[electrofelix]

@hswong3i that's great news, I've seen a slight improvement in my time available and there is some interest from others becoming maintainers so hopefully things will start moving again.

[abbbi]

hi, @electrofelix

@hswong3i that's great news, I've seen a slight improvement in my time available and there is some interest from others becoming maintainers so hopefully things will start moving again.

ive made an attempt to run the current QA scripts within travis CI. In my fork of the QA repository you can find an travis file that:

• Clones vagrant-libvirt master
• Reverts commit 608037c because i was not able to vagrant up within the travis VM with this one, some strange error regarding ruby syntax:

/home/travis/build/abbbi/vagrant-libvirt-qa/vagrant-libvirt/lib/vagrant-libvirt/action/handle_box_image.rb:89: syntax error, unexpected tIDENTIFIER, expecting keyword_do or '{' or '(' (SyntaxError)
1539...         owner: storage_uid env,
1540...                            ^~~

• Bundle/install vagrant-libvirt
• Installs the vagrant-reload plugin working around a json 2.1.0 vs json 2.3.0 gem conflict i couldnt figure out
• Starts the QA script

See:

https://github.com/abbbi/vagrant-libvirt-qa/blob/travis-ci/.travis.yml

Obviously this need some more work on the QA scripts (spinning up ubuntu1804 within travis-ci just to install vagrant and the actual vagrant-libvirt version doesnt make much sense if you could do it directly in travis-ci too), maybe someone else has fun staring at travis-ci logs, heres one from a test build i attempted:

https://travis-ci.org/github/abbbi/vagrant-libvirt-qa/jobs/676986442

I think it would make more sense to have an layout like in my vagrant-libvirt branch master_qa_travis:

https://github.com/abbbi/vagrant-libvirt/tree/master_qa_travis

• have a .travis.yml that fetches and builds vagrant/vagrant-libvirt master
• have defined boxes in tests/ that are spinned up and checked against various options like:
  ** does vagrant up work with a simple default definition
  ** does vagrant destroy work
  ** does provisioning via shell work
  ** does vagrant up work with a defintion that has a second disk and does the disk show up in the vm?
  ** are the settings specified within the vagrantfile are applied to the libvirt xml definition?
  etc etc etc..

[ladar]

@electrofelix I saw this. I've been wanting to add/improve the CI tests I use for the Roboxes for awhile.

I did a little bit of development work along these lines. Basically I created a script which tried to emulate the actions of a a user. Ie, vagrant init && vagrant up && vagrant ssh to ensure that each box worked as intended. Last I checked all the libvirt Roboxes passed this test.

I then got started on writing test cases, where I'd use vagrant ssh -c "COMMAND" to test basic functionality inside the box, like whether passwordless sudo was working, along testing that a few basic commands like cat, grep, sed, awk, etc were installed/working.

Unfortunately the Roboxes project got too big to keep testing all the boxes at once like this, and I never got around to breaking up the script and creating CI jobs which test the individual distros. That way I could test the more popular distros/releases daily, wnile relegating the less popular ones to weekly/monthly.

Anyways, it looks like you might be picking up where I left off. at least with the vagrant-libvirt-qa repo. From what I could tell, only generic/debian10 is being tested by the workflow in this repo.

Anyways, I wanted to say, if you do notice a problem with any of the Roboxes, I'd like to know.

I also thought I'd mention @siddharthvipul ... he maintains the CentOS CI infrastructure, and he might be able to facilitate access to a test environment that runs on metal. I spoke to him about using their systems for the Roboxes project at Flock in 2019, but never found the time to follow up. Updating box configs, and rebuilding the images every 1-3 weeks seems to eat more time than I have already.

[electrofelix]

@ladar for the moment vagrant-libvirt-qa is focused on validating the installation steps only and ensuring that required libraries can be called on the various distros, it's not currently looking at testing the boxes or anything within the boxes due to the lack of being able to use KVM in default GitHub workflows.
If that changes I can switch from using the docker images to launching a tinycore VM to using the libvirt vagrant boxes for the distros being tested.

Yes, there is one test using generic/debian10, because it doesn't work for the tinycore image, but I've limited the usage of proper distros due to using qemu rather than KVM for running them.

I'll try and get to looking at the centos ci infrastructure as an alternative, have a few tasks so probably looks like following for priorities (with misc bugs in between)

• finish multi disk support (latest issue is device assignment with halt then up)
• migrate the integration tests in this repo from bats to rspec using filters/tags
• redo the README to split install, config, etc into separate pages instead of all-in-one
• test distros using libvirt boxes (nested KVM)

[l-monninger]

@electrofelix I'm out of work right now and want to get #1713 fixed, so I'd be happy to join in the effort. If someone could take some time to hop on a call and get me a bit more oriented, that'd be great.

To CI/CD items, do we have any budget for cloud resources?

[electrofelix]

@l-monninger unfortunately I'm completely swamped between work, though I can give you a summary in that issue of what the underlying problem is for installation as well as some possible options for what might be needed.