Today foreman-installer is unintentionally quite tied to the system's hostname. This necessitates tools like katello-change-hostname. In foremanctl I'd like to decouple it fully, which aligns with a containerized model.
A use cases that I'd like to see work: install on 1 hostname, then change it and keep serving the application on the old.
# hostname
foreman.example.com
# foremanctl deploy
# hostnamectl hostname host12345.example.com
# foremanctl deploy
# curl https://foreman.example.com
valid output here
Another is to install straight away on a different service name:
# hostname
host12345.example.com
# foremanctl deploy --service-name foreman.example.com
# curl https://foreman.example.com
valid output here
The exact parameter name is up for debate.
Today we use the FQDN fact too often and that's IMHO an anti-pattern. For example:
|
- "{{ ansible_facts['fqdn'] }}" |
|
pulp_content_origin: "https://{{ ansible_facts['fqdn'] }}" |
|
pulp_pulp_url: "https://{{ ansible_facts['fqdn'] }}" |
Today foreman-installer is unintentionally quite tied to the system's hostname. This necessitates tools like
katello-change-hostname. In foremanctl I'd like to decouple it fully, which aligns with a containerized model.A use cases that I'd like to see work: install on 1 hostname, then change it and keep serving the application on the old.
Another is to install straight away on a different service name:
The exact parameter name is up for debate.
Today we use the FQDN fact too often and that's IMHO an anti-pattern. For example:
foremanctl/src/vars/base.yaml
Line 3 in 099a9fe
foremanctl/src/vars/base.yaml
Lines 34 to 35 in 099a9fe