- Martin Pitt: Why is there an "install the test" step? That seems thoroughly unnecessary with keeping the tests in dist-git, and in fact should be avoided as
/usr/really should remain package manager territory.
- Stef Walter: Is the run-tests.yml in the top level of the dist-git repo? If not, the standard should document the subdirectory that it lives in. The examples are confusing here although the standard says the tests are stored in dist-git the examples are not dist-git style repositories.
- Stef Walter: By default, Ansible sets the current directory to the one that stores the playbook. The output artifacts always end up in the same directory as
run-tests.yml. Should we make an environment variable or somehow specify a fixed directory where they should go?
- Handling test subjects in Ansible is hard. Should we have different entry point scripts for different kinds of test subjects? For example
test-ostree.yml. These playbooks could share Ansible roles and modules, or invoke one another (eg: against a VM the first ansible playbook provisioned).
- re "thinking of linch-pin": These things come/go, better to reference the cloud-control bits indirectly. This can be done simply in ansible by a role that:
* The inventory-name of a host is defined in a variable * Run a list of asserts, defined in a variable (verifies expected state) * Run a command defined by a variable, output expected to be / parsed as YAML. * Use add_host against the output YAML * Profit
Just make that role shared via the central-repo, and every package can use whatever provisioning system/setup/script it wants to.