From Fedora Project Wiki

m
m
 
Line 9: Line 9:
 
* 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:
 
* 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
+
    * 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 list of asserts, defined in a variable (verifies expected state)
  * Run a command defined by a variable, output expected to be / parsed as YAML.
+
    * Run a command defined by a variable, output expected to be / parsed as YAML.
  * Use add_host against the output YAML
+
    * Use add_host against the output YAML
  * Profit
+
    * Profit
  
 
+
Just make that role shared via the central-repo, and every package can use whatever provisioning system/setup/script it wants to.
  Just make that role shared via the central-repo, and every package can use whatever  
 
  provisioning system/setup/script it wants to.
 

Latest revision as of 15:11, 13 July 2017

  • 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-rpm.yml and test-qcow2.yml and test-module.yml and 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.