Closed ericzolf closed 2 years ago
It isn't really ready for proper review but I need to go and I don't want to block anybody willing to review and merge, it should work as it is, even if it isn't nice (but I can improve further next year).
As discussed per chat, the inventory-template is now just two big loops going over variables (one for the hosts, two for variables, secret or not-secret). This allows to maintain the group and variables only in defaults/main.yml
and keep the template nice and tidy.
As an example, my inventory looks like this (don't do this in production with the ansible_password all over the place):
---
aap_setup_prep_inv_nodes:
automationcontroller:
autoctl1.ewl.example.com: "ansible_user={{ ansible_user }} ansible_password={{ ansible_password }} ansible_become_password={{ ansible_become_password }} ansible_become=True"
autoctl2.ewl.example.com: "ansible_user={{ ansible_user }} ansible_password={{ ansible_password }} ansible_become_password={{ ansible_become_password }} ansible_become=True"
database:
autodb.ewl.example.com: "ansible_user={{ ansible_user }} ansible_password={{ ansible_password }} ansible_become_password={{ ansible_become_password }} ansible_become=True"
automationhub:
autohub.ewl.example.com: "ansible_user={{ ansible_user }} ansible_password={{ ansible_password }} ansible_become_password={{ ansible_become_password }} ansible_become=True"
aap_setup_prep_inv_vars:
all:
# workaround to avoid enabling the codeready repo on the autohub server
pulp_rhel_codeready_repo: []
## CONTROLLER PARAMETERS ##
admin_password: '{{ ansible_password }}'
## CONTROLLER DATABASE PARAMETERS ##
pg_password: '{{ ansible_password }}'
pg_host: 'autodb.ewl.example.com'
pg_port: '5432'
pg_database: 'awx'
pg_username: 'awx'
pg_sslmode: 'prefer' # set to 'verify-full' for client-side enforced SSL
## AUTOMATION HUB PARAMETERS ##
automationhub_admin_password: '{{ ansible_password }}'
## AUTOMATION HUB DATABASE PARAMETERS ##
automationhub_pg_host: 'autodb.ewl.example.com'
automationhub_pg_port: '5432'
automationhub_pg_database: 'automationhub'
automationhub_pg_username: 'automationhub'
automationhub_pg_password: '{{ ansible_password }}'
automationhub_pg_sslmode: 'prefer'
And my vault looks like this:
---
aap_setup_prep_inv_secrets:
all:
registry_username: "123456789|aap21-myuser"
registry_password: "someverylongstringverysecret"
And the resulting inventory looks like:
[automationcontroller]
autoctl1.ewl.example.com ansible_user=myuser ansible_password=redhat ansible_become_password=redhat ansible_become=True
autoctl2.ewl.example.com ansible_user=myuser ansible_password=redhat ansible_become_password=redhat ansible_become=True
[database]
autodb.ewl.example.com ansible_user=myuser ansible_password=redhat ansible_become_password=redhat ansible_become=True
[automationhub]
autohub.ewl.example.com ansible_user=myuser ansible_password=redhat ansible_become_password=redhat ansible_become=True
[all:vars]
pulp_rhel_codeready_repo=[]
admin_password=redhat
pg_password=redhat
pg_host=autodb.ewl.example.com
pg_port=5432
pg_database=awx
pg_username=awx
pg_sslmode=prefer
automationhub_admin_password=redhat
automationhub_pg_host=autodb.ewl.example.com
automationhub_pg_port=5432
automationhub_pg_database=automationhub
automationhub_pg_username=automationhub
automationhub_pg_password=redhat
automationhub_pg_sslmode=prefer
registry_username=123456789|aap21-myuser
registry_password=someverylongstringverysecret
By lack of time, I didn't test it till the end, but looks OK to me :smiley:
This looks good going to do some fiddiling or other things, I was going to test to see if the setup.sh can just take a yaml file like our tower config that the user would setup. It should work for everything but the groups/hosts. Going to do some testing, but Almost think thats the better option :)
This looks good going to do some fiddiling or other things, I was going to test to see if the setup.sh can just take a yaml file like our tower config that the user would setup. It should work for everything but the groups/hosts. Going to do some testing, but Almost think thats the better option :)
The issue with YAML is that it's more difficult to generate by template due to the changing indentations. Also, prepare
is split from install
exactly for people being able to push their own inventory between the two steps, if they want.
had not considered that, was testing things to see what worked, and throwing things at the wall to see what sticks/works. At this point agree with the separation of prepare/install. I am almost thinking that this is something that might be easier solved by making improvements to the installer, to allow variable insertion, or kicking off the playbook itself. Still noodling around though on what would be best.
Not sure when the edit comment was made, but I like the looks of it. I think its a LOT more maintainable, we should like have an example with things preset, but that's personal choice, and makes it so if more variables are introduced the 'install' role doesn't need to be updated.
Ready for merging!
What does this PR do?
Add aap_setup_prepare role
How should this be tested?
install AAP 2.1...
Is there a relevant Issue open for this?
n/a
Other Relevant info, PRs, etc.
It works so far (I successfully installed a complete cluster on this basis) but there is still quite a lot to do: