standard-test-roles

#49 inventory: vagrant provider
Merged by stefw. Opened by merlinm.
Unknown source master

Download 49.patch

This adds an ansible dynamic inventory provider script for vagrant.

Currently only libvirt based vagrant boxes are supported. Also, the CPU of the test running machine must have KVM hardware virtualization enabled to run vagrant--and the script will raise an explanatory exception if it isn't.

It works analogously to the other ansible dynamic inventory provider scripts for docker, qcow2, etc. To use it, set the ANSIBLE_INVENTORY environment variable to the path of the script (or a directory containing the script) and set the TEST_SUBJECTS environment variable to include either a URL or local path to a vagrant box file. (Note: vagrant caches boxes, so there is no need to be concerned about repeated large downloads if a box is specified by URL.)

For example:

$ sudo -s
# export ANSIBLE_INVENTORY=.../path/to/inventory/standard-inventory-vagrant
# export TEST_SUBJECTS="https://download.fedoraproject.org/pub/fedora/linux/releases/26/CloudImages/x86_64/images/Fedora-Cloud-Base-Vagrant-26-1.5.x86_64.vagrant-libvirt.box"
# ansible-playbook --tags classic tests.yml

It writes an inventory-vagrant.log log file to the artifacts directory.

Since the required vagrant and vagrant-libvirt packages are very heavy on dependences, and the script won't necessary be used by everyone, it currently just checks for the presence of the required packages and raises an exception if they are missing.
Question: is this an appropriate way to handle the package requirements? Or should they be included as Recommends in the package SPEC file anyhow? Or should the script try to install the packages if it finds them missing?

What is the full testing story behind this?

The goal of the inventory scripts is to turn "test subjects" (ie: something testable) into Ansible Inventory such that tests can be run against that subject.

Are we, or do we, plan to have Vagrant boxes as "test subjects"?

Answering this question helps answer many that follow, such as the above package requirements question.

If the answer is: "no this is just a devel tool" ... then shouldn't this go into the scripts directory ... a file to to be used explicitly ... and not try to fit into the TEST_SUBJECTS environment parsing concepts?

@stefw I feel this fits exactly into the ansible dynamic inventory test subjects scheme. Considering the Fedora Cloud Working Group publishes a set of Vagrant Fedora images including Atomic, they are perfectly reasonable test subjects.

Makes sense.

So the question is how to handle dependencies.

Can the inventory script opportunistically install the dependencies on the executor host its running on? What do you think? The tests themselves can and will do such things to the executor host, why not the inventory scripts.

I know we do something similar with standard-inventory-docker ... albeit inside the test subject. So that's a bit different.

Can the inventory script opportunistically install the dependencies on the executor host its running on?

Absolutely. That was the gist of my last question in the PR summary. Apologies for not explaining myself very clearly.

If you find that an acceptable approach, I'll make that revision.

1 new commit added

  • inventory: opportunistically install package dependencies for vagrant provider on executor host

This works well. Tested with Fedora-Cloud-Base-Vagrant-26-1.5.x86_64.vagrant-libvirt.box

I'll merge this but have one more question:

  • Will you update the spec to say that "*.box" is a TEST_SUBJECT for vagrant boxes?

Pull-Request has been merged by stefw

@stefw Thank you.

Will you update the spec to say that "*.box" is a TEST_SUBJECT for vagrant boxes?

Yes--as soon as a fresh release of the standard-test-roles package is in the updates pipeline...
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.