16:01:37 #startmeeting openstack_ansible_meeting 16:01:38 Meeting started Tue Mar 19 16:01:37 2019 UTC and is due to finish in 60 minutes. The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:41 The meeting name has been set to 'openstack_ansible_meeting' 16:02:00 o/ 16:02:07 So on record I’m in favour of Mariabackup 16:02:21 o/ 16:02:27 \o/ 16:05:15 #topic office hours 16:05:25 jrosser: odyssey4me ^^ about mariabackup 16:05:32 or we can also do good ol rsync 16:07:03 is it mariabackup or mariadbbackup? 16:07:58 o/ 16:09:32 o/ 16:10:01 o/ 16:12:31 o/ hello 16:14:35 o/ 16:14:57 mnaser: I have submitted the request for our first alpha of stein. 16:15:05 I would like to freeze things again for RC soon. 16:15:11 when are we ready to branch ? 16:15:52 god, topic office hours is confusing me, should discuss about having office hours, or is this office hours? 16:15:53 and for the record, I'm going to do the cycle highlights 16:16:26 Jonathan Rosser proposed openstack/openstack-ansible master: [WIP] AIO - Create HAProxy self-signed certificates during host prep https://review.openstack.org/644555 16:18:16 guilhermesp: thanks there 16:19:37 It’s just office hours at this point. 16:20:00 I think we should branch after release imho... 16:20:52 after release of openstack upstream projects? 16:21:11 I mean other projects, upstream is kinda weird here 16:21:15 on RDO side, we have started building packages for stein 16:21:38 mnaser: fine for me 16:21:53 it means less backporting 16:22:34 https://trunk.rdoproject.org/centos7-stein/report.html 16:23:20 i think after stein has been released in terms of the tarballs from releases.o.o 16:23:26 that way we consume something that fully works 16:24:00 Don't we usually cut like 2 weeks after everyone else? 16:24:32 we could do that too as well 16:25:01 the thing is i feel that our code is still moving often and backports might be missed, we're getting much more stable 16:25:04 spotz: we haven't done that at previous release 16:25:12 spotz: we don't have that mandatory requirement anymore 16:25:18 so we could evaluate 2 weeks after and see what happens, but i think nailing down a very stable release and then pushing it out is better 16:25:20 it was useful to wait a little tbh 16:25:25 evrardjp: But it was a sensible one:) 16:25:34 that way we dont have to backport stuff like stein support for $some_distro or so 16:25:38 +2 16:25:50 well here I am concerned that we'll branch very late 16:25:56 and then release maybe shortly after 16:26:07 but we have a few months now, so we will have time 16:26:45 mnaser: I would like to propose branching when others are doing it, so we can bump things properly. No problem with requirements either 16:26:58 and it takes time for the dust to settle when branching 16:27:03 "oh we forgot this" 16:27:29 i'm curious on what's the concern of us release a month after openstack is out considering it sa deployment project 16:27:36 tripleo releases well after once they have everything nailed down 16:28:01 That's how I thougt we were still doing it, weeks vs months though 16:29:03 we should put a bit of effort now into housekeeping - like the very old galera version 16:29:32 mnaser: it's no problem for releasing late 16:29:42 I am just concerned about branching late. 16:30:18 I would prefer branching when all the others have branched 16:30:29 or most of the others have branched 16:30:33 maybe i'm not following but i'm not sure why we cant just branch and then release afterwards. if we branch when nova branched but our mariadb is still pushing 10.1 16:30:46 and now we gotta backport a whole collection of patches to get a *stable* branch to use 10.3 16:31:41 I am confused -- when do you want to branch? 16:32:14 If it's after the official release of other projects, it means during a time we'll be testing those project's master branch, which might be less stable than their newly created stable branch 16:33:08 imho i dont think our biggest problem is projects breaking us, it's more us breaking us 16:33:12 so i don't know if that's as much of a risk 16:33:15 i would like others to chime in though 16:33:48 Nicolas Bock proposed openstack/openstack-ansible stable/rocky: [WIP] Default to setting --concurrency until SUSE package is merged https://review.openstack.org/644612 16:34:21 Stable is a relative term but I think we need to wait until say nova says we're good, then have the time to make sure we're good before we say we're good:) 16:34:49 that's the thing, when nova branches, master will be for master dev 16:35:30 I don't see the backport as massively painful. 16:35:59 I agree with spotz and evrardjp ... it is even safer and clear if we are breaking us 16:36:06 iirc for R we had to backport a ton of stuff. odyssey4me did a really great job of keeping track of what was going into master and backporting the necessary stuff. 16:36:29 I agree on branching late 16:36:40 but at a point we should say stop 16:36:43 I am merely asking when 16:37:12 for me, when other project branch is a good time, because it's clear 16:37:27 but i dont know if that's enough time for us to clean up our current state 16:37:53 mnaser: you got a todo list so we know what done looks like? 16:38:28 jrosser: from the top of my head -- updating our tests to use integrated repo for all roles, mariadb improvements, upgrade tests addition 16:38:57 these are big things 16:39:07 we also have a big issue with upgrades because we now use the in-distro packaging for rabbitmq 16:39:11 in master 16:39:20 and 'upstream' in backports 16:39:26 err 16:39:33 'upstream' as in upstream rabbitmq in stable 16:39:47 which will result in a downgrade during upgrades... no bueno 16:40:05 and the python_venv_build clean up work, in order to eliminate the repo container by default too 16:40:22 i think those a pretty critical for release if we want to put a proper stamp of approval. i'm open if people disagree 16:40:55 I am not disagreeing with the plan, I just don't have resources to put in so big changes 16:41:18 indeed.. we can reduce the # of things 16:41:21 technically openstack-ansible is "cycle-trailing", like other deployment systems, so there is a bit of time after the branching of the managed projects 16:41:45 i just think being 'goal' based rather than 'time' based might be better approach. 16:42:25 tosky: 3 months iirc 16:42:45 yes 3 months 16:42:53 https://releases.openstack.org/reference/release_models.html#cycle-trailing 16:42:54 https://docs.openstack.org/project-team-guide/release-management.html#trailing-the-common-cycle 16:43:38 god we have duplicate docs there -- that's bad. 16:43:46 heheheheh 16:49:47 Hello, I just upgraded from Ocata to Pike and I have duplicate hypervisor records (every hypervisor is seen twice in openstack hypervisor list), overview page in horizon is stuck as well... It looks like its related to this bug: https://bugs.launchpad.net/openstack-ansible/+bug/1736731. looks like an open bug? how can i fix this? Thank you! 16:49:50 Launchpad bug 1736731 in openstack-ansible "os_nova might create a duplicate cell1" [High,Confirmed] - Assigned to Jean-Philippe Evrard (jean-philippe-evrard) 16:50:23 on a totally unscientific grep we still have 7 repos containing policy.json.j2 - finishing off the smart sources work feels important too 16:51:50 yep, what jrosser brings up too 16:51:59 i think we need to start working on this and see where we land 16:53:42 every time i look through gate run logs the service journals are full of config deprecation warnings too 16:53:50 ok so we have a growing list with things that should be fixed/improved before we come up branching... like finishing the smart sources and fixing mariadb stuff but not a decision when to branch after the others right? 16:59:34 jrosser, guilhermesp: i agree, maybe we should setup a hack day 16:59:45 agreed mnaser 17:00:25 that would be time better spend than another bug sqaush day currently 17:02:03 hacking stuff around could avoid the need of bug squash days :P 17:03:50 #endmeeting