Make contribution to foreman-ansible-modules easier

[bagasse]

SUMMARY

Today, there is no default test env documented or provided. This can be an obstacle to contributions on some parts of foreman-ansible-modules that need a 'big' setup (read a lot of plugins / proxy features enabled)

Discution started here #374 thanks to @mdellweg.

Ideas:

• Provide All in one forklift box that can be used out of the box to test/record most of foreman-ansible-modules
• Provides sane defaults in test_playbooks to point to this setup (foreman server, smart proxies names...)
• Add some docs on README on how to setup this env (link to forlift docs, required forklift settings...)

Some starting points:

cat playbooks/foreman_ansible_modules.yml 
---
# foreman-ansible-modules default test env setup
- name: Apply katello playbook
  import_playbook: katello.yml
- name: Apply libvirt playbook
  import_playbook: libvirt.yml

cat vagrant/settings.yaml
---
memory: 4608
cpus: 2
scale_memory: 1
scale_cpus: 1
sync_type: 'rsync'

cachier:
  mount_options: ['rw', 'vers=3', 'tcp', 'nolock']

ssh_forward_agent: True

domain: 'example.com'

foreman:
    box:   centos7
    memory: 6144
    ansible:
      playbook: 'playbooks/foreman_ansible_modules.yml'
      variables:
        foreman_repositories_version: 1.22
        katello_repositories_version: 3.12
        foreman_installer_additional_packages:
          - tfm-rubygem-foreman_dhcp_browser
          - tfm-rubygem-foreman_expire_hosts
          - tfm-rubygem-ovirt_provision_plugin
          - katello
        foreman_installer_options:
          - '--enable-foreman-compute-openstack'
          - '--enable-foreman-compute-libvirt'
          - '--enable-foreman-compute-ovirt'
          - '--enable-foreman-plugin-openscap'
          - '--enable-foreman-proxy-plugin-openscap'
          - '--foreman-proxy-dns=true'
          - '--foreman-proxy-bmc=true'
          - '--foreman-proxy-realm'

ISSUE TYPE

• Feature Idea

[evgeni]

One thing that @mdellweg and I discussed yesterday evening over beer was: we could extend the existing playbooks with a play that describes the setup and points to a non-existing host (so ansible will skip that by default). And the user then can go and add that host to the inventory, pointing to their base install and we extend that base install. This is somewhere between your idea 1 and 2.

I think extending/updating documentation should happen regardless of the automation part of this feature, because we have some slightly outdated bits in there anyways.

[evgeni]

Further talks with @ekohl @sean797 and @mdellweg: for "external" services (like a libvirt that we might need for the CR modules) we could provide an additional forklift box that gets fully set up and the user then just needs to configure the URL to said box properly

Some POC can be seen in https://github.com/theforeman/forklift/pull/932 where I tried to do the same for the kubevirt CR (the PR is 90% done, and kubevirt needs more setup than libvirt, but you get the idea.

Bonus points, the same box can be then used by @ekohl in the end-to-end tests he is planning.

[evgeni]

@evgeni will try to list up the needed changes and then open up separate issues that need tackling

[evgeni]

So what I now did in foreman_host was adding a play against a fictional foreman host that does the needed steps:

https://github.com/theforeman/foreman-ansible-modules/blob/8c717ce33adabd4b178c6c9ceb7c11197ec182e9/tests/test_playbooks/host.yml#L2-L10