Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kickstart_repository (field "synced content") is not correctly set when creating a host via the ansibel module redhat.satellite.host #1090

Closed
bertelsp opened this issue Dec 8, 2020 · 12 comments · Fixed by #1132
Assignees

Comments

@bertelsp
Copy link

bertelsp commented Dec 8, 2020

SUMMARY

Using the ansible module redhat.satellite.host to create a host on our Satellite server it seems the selected kickstart_repository is not correctly set in field "synced content" (although it is correctly set in the playbook). The field on the satellite host remains gray.
When trying to kickstart the host anyway the URL refers to a library URL instead to a lifecycle environment URL.
When doing this through the Satellite GUI, this it correctly set upon selecting the operating system (dynamically updated).

ISSUE TYPE
  • Bug Report
ANSIBLE VERSION

ansible 2.8.16

KATELLO/FOREMAN VERSION

tfm-rubygem-katello-3.14.0.32-1.el7sat.noarch
foreman-1.24.1.32-1.el7sat.noarch

STEPS TO REPRODUCE

run playbook

    - name: "Create host {{ host.name }}"
      redhat.satellite.host:
        name: "{{ host.name }}.{{ domain_name }}"
        organization: "{{ organization }}"
        location: "{{ datacenter }}"
        hostgroup: "hg-{{ organization }}-{{ datacenter }}"
        lifecycle_environment: "{{ host.lifecycle_environment }}"
        content_view: "{{ host.content_view }}"
        architecture: "{{ host.architecture }}"
        operatingsystem: "{{ host.operatingsystem }}"
        kickstart_repository: "{{ host.kickstart_repository }}"
        ptable: "Kickstart default {{ organization }}"
        pxe_loader: "{{ host.pxe_loader }}"
        root_pass: "{{ host.root_pass }}"
        mac: "{{ network.mac }}"
        subnet: "{{ network.name }}/{{ network.bits }}"
        ip: "{{ network.ip }}"
        build: true
        comment : "{{ host.comment }}"
        state: present
        server_url: "{{ server_url }}"
        username: "{{ username }}"
        password: "{{ password }}"
EXPECTED RESULTS

Host is created but the field "Synced Content" remains empty where it should mention the kickstart repo.
When starting the server the URL to the kickstart image is incorrect.

The used URL refers to a Library path instead of a lifecycle path (should be test in our case)
http://capsule_server/pulp/repos/organisation/Library/content/dist/rhel/server/7/7.6/x86_64/kickstart/images/pxeboot/vmlinuz... No such file or directory

@evgeni
Copy link
Member

evgeni commented Dec 8, 2020

can you try setting the content_source parameter too? something like content_source: capsule_server should do it

@bertelsp
Copy link
Author

bertelsp commented Dec 8, 2020

The host group I'm using in my playbook is normally setting the content_source.
But I tried setting the "content_source: capsule_server" anyway.
Result: no difference, the field "synced content" on my satellite server host definition remains empty.

@evgeni
Copy link
Member

evgeni commented Dec 8, 2020

Thanks for trying! Was worth a shot. I'll see if we can repro this and why it happens.

@evgeni
Copy link
Member

evgeni commented Dec 8, 2020

just for clarification, if you edit the host in the UI, the only thing you need to set to get a working host is the "synced content" thing?

@evgeni
Copy link
Member

evgeni commented Dec 22, 2020

So I tried to reproduce this, and couldn't. The created host had a "synced content" KS as desired.

Here is the playbook I used

- hosts: localhost
  gather_facts: false
  vars:
    foreman_username: admin
    foreman_password: changeme
    foreman_url: https://foreman.example.com
    foreman_validate_certs: False
    foreman_initial_organization: Default Organization
  tasks:
    - name: create host
      theforeman.foreman.host:
        username: "{{ foreman_username }}"
        password: "{{ foreman_password }}"
        server_url: "{{ foreman_url }}"
        validate_certs: "{{ foreman_validate_certs }}"
        organization: "{{ foreman_initial_organization }}"
        location: "Default Location"
        hostgroup: "egolov-test"
        name: 'test1.kangae.example.com'
        build: False
        managed: True
        lifecycle_environment: Library
        content_view: "Default Organization View"
        content_source: foreman.example.com
        kickstart_repository: Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.4
        mac: fe:fe:fe:fe:fe:fe

@evgeni
Copy link
Member

evgeni commented Dec 22, 2020

Is the KS repository you're trying to set in the Lifecycle Environment/Content View you assign?

@evgeni
Copy link
Member

evgeni commented Dec 22, 2020

Or maybe the operatingsystem you set doesn't have one attached for some reason?

@evgeni
Copy link
Member

evgeni commented Dec 22, 2020

Okay, yeah, setting operatingsystem: RedHat 7.9 while my system has no 7.9 kickstart synced results in the following:

Screenshot from 2020-12-22 11-47-52

does that match what you see?

@evgeni
Copy link
Member

evgeni commented Dec 24, 2020

One more thought: if it's CV/LCE, we can easily enforce those when searching for the KS repo and yield an appropriate error if it's not found.

But I am not sure how to do the same for the OS.

@evgeni
Copy link
Member

evgeni commented Jan 20, 2021

ping @bertelsp, were you able to find out why the synced content wasn't selected in your case?

@evgeni evgeni self-assigned this Jan 20, 2021
@bertelsp
Copy link
Author

bertelsp commented Jan 20, 2021 via email

@evgeni
Copy link
Member

evgeni commented Jan 22, 2021

Ah, wonderful, there is a reproducer setup in the BZ, I'll follow up with the data I can obtain there.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants