foreman_operatingsystem provisioning_templates does not work

[m-czernek]

SUMMARY

The foreman_operatingsystem module does not work when the provisioning_templates parameter is set. There seems to be an architectural issue as well as implementation issue.

Implementation issue When I specify the provisioning_templates list, the template is not selected. When I re-run the playbook again, the result is changed and all the templates disappear from an OS object (see in GUI or API).

Consequently, the module seems:

• not to be idempotent (multiple calls break the OS object in Satellite)
• not working with the provisioning_templates (the first call does not set the template correctly)

When the module is called without the template list, it seems to work correctly.

Architectural issue Each OS object has a number of provisioning templates:

As a user, I want to be able to set one particular template (i.e. Provisioning template) and let the rest be the default. The provisioning_templates parameter is a list of names, without the possibility to choose the template kind.

It's of course possible I'm missing something, but how does the foreman_operatingsystem module know which template_name is assigned to which kind of provisioning template?

ISSUE TYPE

• Bug Report

ANSIBLE VERSION

ansible 2.8.3
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/ansible/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Sep 12 2018, 05:31:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]

APYPIE VERSION

python2-apypie-0.1.0-1.el7.noarch (installed from https://copr.fedorainfracloud.org/coprs/evgeni/foreman-ansible-modules)

FAM VERSION

ansible-collection-theforeman-foreman-0.1.0-0.1.pre.master.20191021082300gitf4e3cd8

(though happens with master version as well)

[m-czernek]

I see that for the architectural problem, we have a separate foreman module. However, the implementation detail stands - if we re-run this module multiple times, the templates seem to get deleted.

We are still testing workarounds. I'll update this issue with our findings.

[evgeni]

can you please provide an example playbook that triggered the issue for you?

[m-czernek]

Reproducing the issue:

- name: "Create OS"
  theforeman.foreman.foreman_operatingsystem:
      username: "{{ rhs_satellite_admin }}"
      password: "{{ rhs_satellite_admin_password }}"
      server_url: "{{ rhs_satellite_server_url }}"
      name: "RedHat"
      description: "RHEL Server 7.7"
      major: "7"
      minor: "7"
      family: "RedHat"
      password_hash: "SHA512"
      architectures: "[ 'x86_64' ]"
      ptables: "[ 'Kickstart default' ]"
      provisioning_templates: "[ 'Kickstart default' ]"
      validate_certs: "{{ rhs_validate_certs }}"

First run:

PLAY [create role] **********************************************************************************************************************************************************

TASK [satellite_create_os_idempotent : Create OS] ***************************************************************************************************************************
Thursday 24 October 2019  14:04:59 +0200 (0:00:00.061)       0:00:00.061 ****** 
changed: [dh2.rh.local -> localhost] => (item={u'major': u'7', u'description': u'RHEL Server 7.7', u'family': u'Redhat', u'os_default_templates': {u'provision': u'SDDC Kickstart Default'}, u'name': u'RedHat', u'ptables': [u'Kickstart default'], u'provisioning_templates': [u'Kickstart default'], u'architectures': [u'x86_64'], u'minor': u'7', u'password_hash': u'SHA512'})

OS looks correct:

Second run (no changes to the variables or anything else):

PLAY [create role] **********************************************************************************************************************************************************

TASK [satellite_create_os_idempotent : Create OS] ***************************************************************************************************************************
Thursday 24 October 2019  14:06:40 +0200 (0:00:00.067)       0:00:00.067 ****** 
changed: [dh2.rh.local -> localhost] => (item={u'major': u'7', u'description': u'RHEL Server 7.7', u'family': u'Redhat', u'os_default_templates': {u'provision': u'SDDC Kickstart Default'}, u'name': u'RedHat', u'ptables': [u'Kickstart default'], u'provisioning_templates': [u'Kickstart default'], u'architectures': [u'x86_64'], u'minor': u'7', u'password_hash': u'SHA512'})

(Note that ^^ is changed and not ok)

Refreshing templates:

Coming back to the issue, I suppose this is a misunderstanding on our part, correct? Is it because we specify only one template, and as a result, everything gets wiped?

At this point, I believe that it's not really a fault of the role itself, but the documentation (which is a bit unclear). Do you agree? If so, I'll create another small MR to address the documentation, so that other people understand what each parameter does

[evgeni]

Probably. At least that would be a valid explanation. Let me look at the API/code.

[evgeni]

Yeah, I think you're right. You have to specify all templates or the update will break the unassigned ones (interestingly, a create seems to fill-up with defaults?)

@Fobhep @mdellweg for visibility, you wrote that module :)

[m-czernek]

The question is, "You have to specify all templates" for what? Why do I have to specify all the templates? What is the added functionality?

And correct, create fills the OS object with defaults.

[mdellweg]

Uhh. I agree, this does not perform particularly nice. But i think, the misconception is additionally fueled by the fact, that the select boxes shown in the screenshots here are what is set by the foreman_os_default_template module, while the list of templates in the foreman_operating_system module only selects which templates are connected to the operating system at all. And if you reduce that list, the corresponding default selections are also wiped. I think, this is already very confusing on the foreman side.

[m-czernek]

@mdellweg I've tried to describe the issue in #554 . Feel free to request changes to the doc of course.