Vagrant-libvirt: 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:

• https://github.com/ansible-community/molecule-vagrant/issues/8#issuecomment-589902704
• 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 608037c15c099161ba3354d5083c4dcb99405fba 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..