On Fri, Apr 17, 2020 at 6:27 AM Federico Iezzi <fiezzi@redhat.com> wrote:
Hi Alex,
Apologies for late answer. First off, I didn't know about 'openstack tripleo config generate ansible', that's pretty cool actually!
There are a couple of things to consider with that ansible.cfg:
When running the cmd, it's really not possible to specify an arbitrary user (in this case using the standard heat-admin)
That works for me. Did you check your ansible.cfg?
(undercloud) [stack@undercloud ~]$ openstack tripleo config generate ansible --deployment-user heat-admin --output-dir ~/config-donwload The --deployment-user value heat-admin does not match the user name executing this command!
To clarify, there's a warning about the username of the user being different from the requested user: (undercloud) [CentOS-8.1 - stack@undercloud test]$ openstack tripleo config generate ansible --deployment-user foo The --deployment-user value foo does not match the user name executing this command! (undercloud) [CentOS-8.1 - stack@undercloud test]$ However, the parameter does work, e.g. I see the remote_user is set to the parameter I specified: (undercloud) [CentOS-8.1 - stack@undercloud test]$ grep foo ~/ansible.cfg remote_user = foo (undercloud) [CentOS-8.1 - stack@undercloud test]$
Then, it's hard-coded the fact_caching_connection always pointing to /var/lib/mistral/ansible_fact_cache which is not accessible by stack user.
Maybe that's a bug you could file in Launchpad? With the move away from Mistral that's going to have to change.
Also, back on my initial proposal, what do you think of always generating an ansible.cfg within the config-download so that users can more easily run ansible?
It's possible someone might want to run it separately and not have a different ansible.cfg snuck in on them. Maybe it's better to propose any needed fixes to 'openstack tripleo config generate ansible' but continue to run it separately. I'd be curious what people working on config-download think of that too.
This would remove any deps from Mistral making the entire process easier.
Ansible is already replacing Mistral: https://specs.openstack.org/openstack/tripleo-specs/specs/ussuri/mistral-to-... Though I assume you're interested in doing this in Train and I don't think the above can be backported. Too big of a change in default behavior. So I assume you'll keep running config-download manually with Train for a while and perhaps the way forward for that is to run these commands: 1. openstack overcloud config download 2. tripleo-ansible-inventory --static-yaml-inventory inventory.yaml 3. openstack tripleo config generate ansible and fix any bugs in the individual tools. John
Cheers, Federico
Federico Iezzi
EMEA Principal Telco Architect
+31-6-5152-9709
On Thu, 9 Apr 2020 at 21:55, Alex Schultz <aschultz@redhat.com> wrote:
Does 'openstack tripleo config generate ansible' not do it for you?
On Thu, Apr 9, 2020 at 12:47 PM Federico Iezzi <fiezzi@redhat.com> wrote:
Hey there,
I've recently played with Config-Download in TripleO. My aim was since the begging running Ansible standalone w/o relying on Mistral. TripleO Ansible [1] can introduce drastic flexibility, IMO much needed to improve the overall experience.
Now, the major road blocker I found, was in relation of Ceph-Ansible. Without the nice ansible.cfg from Mistral, it's pretty much a bit hard running Ansible standalone. Yes, manually exporting the various Ansible paths can do the trick, but down the road, more and more roles may be introduced forcing users to always discover the latest ones. For example, in my case without the original ansible.cfg, the issue was the following braking ceph-ansible.
$ ansible-playbook -i inventory.yaml --private-key ~/.ssh/id_rsa --become deploy_steps_playbook.yaml The error appears to be in '/home/stack/config-download/external_deploy_steps_tasks.yaml': line 13, column 13, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - import_role: role: ceph ^ here
To solve it, I wrote this simple [2] Python script that relies on write_default_ansible_cfg from ansible in tripleo_common. The result is that, after the heat provisioning [3] I generate the config-download folder (with all its contents), the inventory and also the ansible.cfg file and ansible standalone can be executed called.
You can find my templates and work at [4]
What do you think about including the ansible.cfg as part of the config-download generation procedure?
Cheers, Federico
[1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployme... [2] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/write_defau... [3] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/005-deploy.... [4] https://github.com/m4r1k/nfvi_lab/tree/osp16