16:15:18 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:15:19 <openstack> Meeting started Tue Jun  4 16:15:18 2019 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:15:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:15:24 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:15:25 <noonedeadpunk> #chair mnaser
16:15:26 <openstack> Current chairs: mnaser noonedeadpunk
16:16:04 <raukadah> \o/
16:16:07 <guilhermesp> sooo our db refactor is almost done https://review.opendev.org/#/q/topic:osa/db-refactor
16:16:17 <guilhermesp> reviews are appreciated. noonedeadpunk already added a comment today
16:16:36 <guilhermesp> evrardjp: not sure if I get your point of how the order of mq and db setup could affect upgrades
16:17:26 <noonedeadpunk> guilhermesp: I think we may implement it afterwards, if decide to do so
16:18:18 <guilhermesp> yeah I think we need to kinda of keep a standart in galera variables for each role, some role vary on the variable name definition, this is not good when we are replicating a pattern acroos all roles
16:20:24 <noonedeadpunk> and as I get from the previous discussion we decided not to backport placement to stein
16:23:04 <mnaser> Yeah i think it won't think it will be a big deal
16:24:23 <odyssey4me> I'll aim to have the upgrade thing done by next Tue, but given the late stage we're in for Stein RC I think we should aim to release as-is rather than try to backport placement... I guess it depends on when we want to release Stein.
16:27:10 <raukadah> I wanted to talk about python3 support for os_tempest
16:27:50 <odyssey4me> Ah yes, we had a plan for py3 support at the PTG and logan- kicked off some patches. Any progress there?
16:28:09 <raukadah> We have two implementation here https://review.opendev.org/#/c/661979/ and https://review.opendev.org/#/c/661994/
16:28:16 <raukadah> which way to go, I am not sure
16:28:38 <raukadah> as we move to one role, we might need to follow the same approach for other distros for consistency
16:29:04 <noonedeadpunk> wow redhat-8 support
16:29:57 <raukadah> noonedeadpunk: yes, making the things ready till centos lands
16:29:58 <odyssey4me> hmm, that'd be a ton simpler if we could change up the way the packages are included in that list
16:30:40 <raukadah> *centos-8
16:31:06 <odyssey4me> until I have time to really think that through, I have no opinion.
16:31:51 <odyssey4me> My only initial thought is that it'd be great if we could simplify how packages get into that list so that we just use a single var and each line has a ternary for the python version.
16:31:56 <raukadah> odyssey4me: you mean based on distro version catogarize the package list?
16:32:44 <raukadah> or using ansible python interpreter version and replace the package name with python prefix?
16:33:23 <mnaser> I tried to do some fedora stuff
16:33:27 <mnaser> To make it work in advance
16:34:02 <odyssey4me> I mean so that the vars file has a ternary something like this instead: https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/vars/main.yml#L21
16:34:58 <odyssey4me> or this: https://opendev.org/openstack/openstack-ansible-ceph_client/src/branch/master/vars/suse.yml#L20
16:36:04 <raukadah> odyssey4me: same approach followed here https://review.opendev.org/#/c/661979/
16:36:18 <raukadah> but sometime ansible_distribution_version behaves weired
16:36:36 <raukadah> may be due to string comparison
16:37:12 <zbr> raukadah: just joined so I may lost some context. I do have an alternative approach for determining package names: https://review.opendev.org/#/c/661994/
16:38:04 <raukadah> zbr: here is the conversation if missed http://paste.openstack.org/show/752504/
16:39:02 <raukadah> zbr: if we are planning to make changes, if it would be good to keep consistency across all roles
16:39:57 <zbr> raukadah: yep, agree. i am for consistency and simplicity.
16:40:35 <zbr> as a note related to ansible_distribution_version -- this can have unexpected values on some versions of ansible, check https://github.com/ansible/ansible/issues/50141
16:41:57 <zbr> as a general rule for distro-specific configuration, I used the layered loading pattern multiple times, it was suggested by ansible team members on a bug I had open, works quite nice and scales well as it allows users to define variance easily.
16:43:07 <raukadah> odyssey4me: venv_python_executable part look reasonable, if it is python2 just replace the package name with that python part with var
16:43:39 <raukadah> instead of distro version compare
16:44:14 <zbr> i am afraid that you cannot rely on venv_python_executable for multiple reasons, one is that it could be "python" that points to python3.
16:45:29 <raukadah> zbr: once they make default python3 to python then it will be a problem
16:46:02 <zbr> one could argue that we could ask for python version itself, but that opens new issues: what if user is running ansible from a machine with py2 and the remote machine is a py3 based distro (or vice-versa). In the end, what package is to be used should be based on distro, not python version.
16:46:35 <zbr> especially as we have many distros with multiple python versions installable at the same time.
16:47:32 <zbr> i do not think that having distro specific files with overrides would be a problem, especially as we need to add them only if they need overridign.
16:48:09 <zbr> so a new shiny distro appears which does not work with defaults, we can just add that file.
16:49:19 <raukadah> so both approach does not looks good
16:49:36 <raukadah> and we also needs consistency what to do then?
16:50:08 <zbr> raukadah: consistency related to? can you give me an example?
16:50:49 <raukadah> zbr: https://opendev.org/openstack/openstack-ansible-ceph_client/src/branch/master/vars/suse.yml -> we follow the same for other role
16:51:23 <raukadah> if we check one role, we can easily go through other role
16:54:26 <zbr> .... i think that one approach does not make the other unusable, they can coexist. still, I do understand your worry about consistency
16:54:59 <raukadah> odyssey4me: mnaser noonedeadpunk guilhermesp what should be follow here ^^?
16:56:26 <zbr> raukadah: do you happen to know which suse versions are supported below 42? is more than one or two?
16:56:39 <raukadah> zbr: nope
16:57:32 <zbr> asking because the layered approach could work with two files:  suse.yml (new config) suse-41.yml (old config)
16:57:35 <raukadah> from above example, it is https://opendev.org/openstack/openstack-ansible-ceph_client/src/branch/master/vars/suse.yml#L20 42 or greater than
16:58:53 <zbr> obviously that if someone would need long ranges, you would be forced to add lots of symlinked files)
16:59:30 <noonedeadpunk> zbr only suse 15 is supported in osa since stein
16:59:37 <zbr> but i think than in practice that is not really the case as support for older versions is dropped at some point.
16:59:54 <raukadah> zbr: but with layered approach, we will end up maintaining multiple release var files
16:59:55 <zbr> so this means that this could be implement with suse-15.yml and suse.yml files.
17:00:18 <raukadah> currently we have one file for each distro
17:00:36 <zbr> yep. for me multiple files is a feature, not a bug. especially as it is easy to compare them and that they no longer need jinja conditionals.
17:00:54 <zbr> also the specific ones do need only *differences*
17:01:10 <zbr> there is no duplicated content between release files.
17:02:11 <noonedeadpunk> zbr regarding only differences, explicit is better than implicit, so I'm personally not sure about that
17:02:11 <zbr> the layered approach assumes that you only define overrides in a minimal number of places.
17:03:28 <noonedeadpunk> and rreading ternary might be even easier, that searching in which file variable is overriden
17:03:29 <zbr> noonedeadpunk: nothing prevents you from duplicating entire config, is a matter of taste.
17:04:12 <zbr> i seen some nested ternaries.... clearly not easy to read.
17:05:09 <zbr> adding config ro rhel-8 and centos-8 would require an ugly jinja conditional construct
17:05:42 <zbr> but with layers you can do some magic: "redhat-8.yml" which covers for both.
17:06:05 <odyssey4me> sorry, was away for dinner
17:07:12 <odyssey4me> ugh, thet whole thing with ansible's detection sucks a bit - although that depends on how python's implemented on the distro I guess
17:08:11 <odyssey4me> but yeah, it may make sense to have a redhat-7.yml and redhat-8.yml where applicable, rather than a generic redhat.yml
17:08:28 <zbr> there is also another aspect that should be considered: maintainability. what happens when a new plugin is added. in how many places we should add this new plugin? do we force the user to add another "ternary" in each distro file?
17:09:17 <odyssey4me> well, os_tempest is currently the only one that has all those ternaries in it - the other roles do not, which is why I think we should simplify the mechanism there, rather than perpetuate it
17:09:32 <odyssey4me> although, for now, I don't have an idea for how to do that
17:10:30 <odyssey4me> I do kinda prefer doing what was done in https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/vars/main.yml - have a dict with platform things, then refer to the dict as necessary instead of using include_vars/with_first_found
17:10:38 <odyssey4me> that way we don't hit ansible pathing nonsense
17:13:30 <raukadah> noonedeadpunk: odyssey4me: zbr ok, then we can go with layered approach where needed, further we can improve to venv_build approach?
17:13:39 <raukadah> if needed
17:14:09 <zbr> sounds resonable
17:14:39 <odyssey4me> the layered approach is the current convention, so yeah - that's best to go with for now I think
17:15:15 <zbr> i still have some doubts related to the use of venv_python_executable approach as I know for sure that at some point python -> python3.
17:15:20 <raukadah> I will work with tripleo team to enable logging for upstream os_tempest so that we have proof things work on boht platform
17:15:29 <zbr> but that is another issue
17:17:34 <zbr> another note: _venv_build_base_distro_package_list is misleading twice: is a dictionary, not a list. and is a dictionary made of os_family and not os_distro !
17:18:19 <zbr> redhat is a family, distros are like rhel, fedora, centos.=, bad variable name invites for bad usage
17:18:35 <odyssey4me> zbr it may help to understand that while venv_python_executable is a role var, not ansible var: https://opendev.org/openstack/ansible-role-python_venv_build/src/branch/master/defaults/main.yml#L98
17:18:56 <odyssey4me> zbr so it's easy enough for us to set it to whatever we choose per platform
17:19:07 <openstackgerrit> Logan V proposed openstack/openstack-ansible-os_heat stable/rocky: Fixed the egg name of heat to openstack_heat  https://review.opendev.org/663103
17:19:21 <zbr> yeah
17:20:53 <openstackgerrit> Jimmy McCrory proposed openstack/openstack-ansible-os_glance master: Fix distro installs on Ubuntu  https://review.opendev.org/662575
17:23:41 <raukadah> odyssey4me: zbr noonedeadpunk thanks! really insightful discussion
17:24:12 <raukadah> mnaser: noonedeadpunk: guilhermesp: I think we can close the meeting if more topic to discuss?
17:24:48 <raukadah> *not more
17:29:20 <noonedeadpunk> #endmeeting