foreman_provisioning_template can't update locked template

[milliams]

SUMMARY

Using the foreman_provisioning_template to manage a provisioning template fails to change it is locked: true is set.

ISSUE TYPE

• Bug Report

ANSIBLE VERSION

ansible 2.6.2
  config file = /home/mw16387/acrc-ansible/ansible.cfg
  configured module search path = [u'/home/mw16387/src/library/foreman-ansible-modules/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]

KATELLO/FOREMAN VERSION

tfm-rubygem-katello-3.7.0-1.el7.noarch
foreman-1.18.0-2.el7.noarch

NAILGUN VERSION

Metadata-Version: 2.1
Version: 0.30.2

STEPS TO REPRODUCE

Running the playbook once with:

- name: create template
  foreman_provisioning_template:
    server_url: https://localhost
    username: admin
    password: "{{ root_password }}"
    verify_ssl: false
    name: My PXELinux
    kind: PXELinux
    template: |
      <%#
        kind: PXELinux
        name: Kickstart default PXELinux
      -%>
      blah blah blah
    locked: true

succeeds correctly. Repeating the run without changing anything correctly identifies that the template hasn't changed and so doesn't run the task.

However, it doesn't work if I change the contents of the template so it becomes:

- name: create template
  foreman_provisioning_template:
    server_url: https://localhost
    username: admin
    password: "{{ root_password }}"
    verify_ssl: false
    name: My PXELinux
    kind: PXELinux
    template: |
      <%#
        kind: PXELinux
        name: Kickstart default PXELinux
      -%>
      foo bar
    locked: true

EXPECTED RESULTS

I would expect it to update the contents of the template even though it is locked. We want to manage these templates via Ansible but prevent users in the web interface from messing with them accidentally.

I expect it would need logic to unlock the template, make the change and then lock it again.

Alternatively, an error message from the module noticing that you're trying to change a locked template would aid debugging.

ACTUAL RESULTS

TASK [foreman : create template] ***********************************
fatal: [foreman-p0.acrc.bris.ac.uk]: FAILED! => {"changed": false, "msg": "Error while updating ProvisioningTemplate: 422 Client Error: Unprocessable Entity for url: https://localhost/api/v2/provisioning_templates/135"}

Looking in /var/log/foreman/production.log I see:

2018-08-02T17:00:38 [E|app|eccea] Unprocessable entity ProvisioningTemplate (id: 135):
  This template is locked. Please clone it to a new template to customize.

[sean797]

I'm not sure if doing this will be expected for everyone. Ultimately you are trying to update a locked template. You could unlock it first, maybe using block and rescue. Really I would suggest using Foreman's RBAC to stop users changing stuff you don't want them to.

[milliams]

Ok, that's reasonable.

In that case I think that improving the error message would be helpful. At present it just prints:

{
  "changed": false,
  "msg": "Error while updating ProvisioningTemplate: 422 Client Error: Unprocessable \
          Entity for url: https://localhost/api/v2/provisioning_templates/135"
}

Is that all that is returned from Foreman? In the Foreman logs there is the message This template is locked. Please clone it to a new template to customize.. Is that returned through the API? If not I guess there's nothing you can do.

[sean797]

Unfortunately, this comes from python-requests (https://github.com/requests/requests/blob/master/requests/models.py#L937) The reason (Unprocessable Entity) comes from the Foreman server, I suspect its probably best to raise an issue with Foreman https://projects.theforeman.org/issues/new

[sean797]

@milliams So it turns out Foreman does return an proper message via API, i've raised SatelliteQE/nailgun#519 to see if can get that error printed to the user.

[evgeni]

Since we moved away from nailgun and merged #505, I think this issue can be closed as you should see the error properly.

Please re-open if you think this is not the case.