Open Stack

On Fri, 17 Apr 2020 at 15:44, John Fulton <johfulto at redhat.com> wrote:
>
> On Fri, Apr 17, 2020 at 6:27 AM Federico Iezzi <fiezzi at 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 at 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 at 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 at 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 at undercloud test]$ grep foo ~/ansible.cfg
> remote_user = foo
> (undercloud) [CentOS-8.1 - stack at undercloud test]$
>

My bad, you're right, that's just a warning and the final result is
the correct one :-)

>
> > 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.

https://bugs.launchpad.net/tripleo/+bug/1873480

Backporting the change in Train would be much appreciated

>
>
> > 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-ansible.html


This sounds VERY promising. I agree that such a backport is complex
and probably not even the right thing to do but having a way to run
Ansible directly is much better than not having it :-)
Also there are plenty of progress recently
https://review.opendev.org/#/q/topic:mistral-removal+OR+topic:mistral_to_ansible

>
> 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.

Correct, just a user here of the final solution and specifically for
the type of customer I work with is OSP16/Train

Thanks,
Federico


>
> 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 at 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 at 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/deployment/ansible_config_download.html#playbooks
> > > > [2] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/write_default_ansible_cfg.py
> > > > [3] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/005-deploy.sh#L18-L68
> > > > [4] https://github.com/m4r1k/nfvi_lab/tree/osp16
> > > >
> > > >
> > >
> >
> >
>