16:15:18 #startmeeting openstack_ansible_meeting 16:15:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:15:24 The meeting name has been set to 'openstack_ansible_meeting' 16:15:25 #chair mnaser 16:15:26 Current chairs: mnaser noonedeadpunk 16:16:04 \o/ 16:16:07 sooo our db refactor is almost done https://review.opendev.org/#/q/topic:osa/db-refactor 16:16:17 reviews are appreciated. noonedeadpunk already added a comment today 16:16:36 evrardjp: not sure if I get your point of how the order of mq and db setup could affect upgrades 16:17:26 guilhermesp: I think we may implement it afterwards, if decide to do so 16:18:18 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 and as I get from the previous discussion we decided not to backport placement to stein 16:23:04 Yeah i think it won't think it will be a big deal 16:24:23 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 I wanted to talk about python3 support for os_tempest 16:27:50 Ah yes, we had a plan for py3 support at the PTG and logan- kicked off some patches. Any progress there? 16:28:09 We have two implementation here https://review.opendev.org/#/c/661979/ and https://review.opendev.org/#/c/661994/ 16:28:16 which way to go, I am not sure 16:28:38 as we move to one role, we might need to follow the same approach for other distros for consistency 16:29:04 wow redhat-8 support 16:29:57 noonedeadpunk: yes, making the things ready till centos lands 16:29:58 hmm, that'd be a ton simpler if we could change up the way the packages are included in that list 16:30:40 *centos-8 16:31:06 until I have time to really think that through, I have no opinion. 16:31:51 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 odyssey4me: you mean based on distro version catogarize the package list? 16:32:44 or using ansible python interpreter version and replace the package name with python prefix? 16:33:23 I tried to do some fedora stuff 16:33:27 To make it work in advance 16:34:02 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 or this: https://opendev.org/openstack/openstack-ansible-ceph_client/src/branch/master/vars/suse.yml#L20 16:36:04 odyssey4me: same approach followed here https://review.opendev.org/#/c/661979/ 16:36:18 but sometime ansible_distribution_version behaves weired 16:36:36 may be due to string comparison 16:37:12 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 zbr: here is the conversation if missed http://paste.openstack.org/show/752504/ 16:39:02 zbr: if we are planning to make changes, if it would be good to keep consistency across all roles 16:39:57 raukadah: yep, agree. i am for consistency and simplicity. 16:40:35 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 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 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 instead of distro version compare 16:44:14 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 zbr: once they make default python3 to python then it will be a problem 16:46:02 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 especially as we have many distros with multiple python versions installable at the same time. 16:47:32 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 so a new shiny distro appears which does not work with defaults, we can just add that file. 16:49:19 so both approach does not looks good 16:49:36 and we also needs consistency what to do then? 16:50:08 raukadah: consistency related to? can you give me an example? 16:50:49 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 if we check one role, we can easily go through other role 16:54:26 .... 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 odyssey4me: mnaser noonedeadpunk guilhermesp what should be follow here ^^? 16:56:26 raukadah: do you happen to know which suse versions are supported below 42? is more than one or two? 16:56:39 zbr: nope 16:57:32 asking because the layered approach could work with two files: suse.yml (new config) suse-41.yml (old config) 16:57:35 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 obviously that if someone would need long ranges, you would be forced to add lots of symlinked files) 16:59:30 zbr only suse 15 is supported in osa since stein 16:59:37 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 zbr: but with layered approach, we will end up maintaining multiple release var files 16:59:55 so this means that this could be implement with suse-15.yml and suse.yml files. 17:00:18 currently we have one file for each distro 17:00:36 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 also the specific ones do need only *differences* 17:01:10 there is no duplicated content between release files. 17:02:11 zbr regarding only differences, explicit is better than implicit, so I'm personally not sure about that 17:02:11 the layered approach assumes that you only define overrides in a minimal number of places. 17:03:28 and rreading ternary might be even easier, that searching in which file variable is overriden 17:03:29 noonedeadpunk: nothing prevents you from duplicating entire config, is a matter of taste. 17:04:12 i seen some nested ternaries.... clearly not easy to read. 17:05:09 adding config ro rhel-8 and centos-8 would require an ugly jinja conditional construct 17:05:42 but with layers you can do some magic: "redhat-8.yml" which covers for both. 17:06:05 sorry, was away for dinner 17:07:12 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 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 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 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 although, for now, I don't have an idea for how to do that 17:10:30 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 that way we don't hit ansible pathing nonsense 17:13:30 noonedeadpunk: odyssey4me: zbr ok, then we can go with layered approach where needed, further we can improve to venv_build approach? 17:13:39 if needed 17:14:09 sounds resonable 17:14:39 the layered approach is the current convention, so yeah - that's best to go with for now I think 17:15:15 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 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 but that is another issue 17:17:34 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 redhat is a family, distros are like rhel, fedora, centos.=, bad variable name invites for bad usage 17:18:35 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 zbr so it's easy enough for us to set it to whatever we choose per platform 17:19:07 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 yeah 17:20:53 Jimmy McCrory proposed openstack/openstack-ansible-os_glance master: Fix distro installs on Ubuntu https://review.opendev.org/662575 17:23:41 odyssey4me: zbr noonedeadpunk thanks! really insightful discussion 17:24:12 mnaser: noonedeadpunk: guilhermesp: I think we can close the meeting if more topic to discuss? 17:24:48 *not more 17:29:20 #endmeeting