| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-21 | |||
| 16:20:16 | gibi | I think the current list is normal given we have a month still | |
| 16:20:25 | bauzas | absolutely right | |
| 16:20:26 | gibi | (a bit less of a month | |
| 16:20:27 | gibi | ) | |
| 16:20:31 | bauzas | I'm not afraid of having extra time | |
| 16:20:36 | gibi | me neither | |
| 16:21:15 | bauzas | but I'd say, take this month as an opportunity to start designing your features, so you can raise your questions at the PTG | |
| 16:21:36 | bauzas | anyway, moving on | |
| 16:21:42 | bauzas | #topic Stable Branches | |
| 16:21:58 | bauzas | (that could last a bit) | |
| 16:22:00 | bauzas | nova's stable/ussuri and stable/train are blocked (due to latest virtualenv uses latest setuptools which removed use_2to3) | |
| 16:22:07 | bauzas | the future proof solution would be to pin virtualenv during tox install for stable branches, otherwise new errors can appear with every new release of setuptools, virtualenv, etc | |
| 16:22:12 | bauzas | until we decide about the right solution we can maybe set lower-constraints job as non-voting ( https://review.opendev.org/809955 ) | |
| 16:22:16 | bauzas | probably placement branches have the same errors | |
| 16:22:21 | bauzas | elodilles: floor is yours | |
| 16:22:30 | gibi | bauzas: yes, this is the same error | |
| 16:22:35 | opendevreview | Merged openstack/nova stable/xena: Add missing __init__.py in nova/db/api https://review.opendev.org/c/openstack/nova/+/810192 | |
| 16:22:47 | gibi | it affects a lot of projects that still uses decorator 3.4 as dep | |
| 16:22:56 | gibi | nova affected from ussuri backwards | |
| 16:23:02 | gibi | placement affected all the way to master | |
| 16:23:08 | gibi | (master fix landed) | |
| 16:23:09 | lyarwood | ah I missed this review sorry | |
| 16:23:11 | bauzas | super awesome | |
| 16:23:31 | sean-k-mooney | we may want to consider droping that dep at some point | |
| 16:23:38 | bauzas | we actually have a longer explanation in the open discussion section | |
| 16:23:55 | bauzas | let's just hold this discussion until that point | |
| 16:24:10 | sean-k-mooney | although we are unlikely to hit the same issue again | |
| 16:24:12 | bauzas | (which we will have 30 mins for) | |
| 16:24:20 | bauzas | #topic Sub/related team Highlights | |
| 16:24:37 | bauzas | Libvirt (bauzas) | |
| 16:24:45 | lyarwood | bauzas: happy to take over the libvirt part now you're PTL btw | |
| 16:24:56 | bauzas | lyarwood: awesome | |
| 16:24:58 | bauzas | I was asking for it | |
| 16:25:03 | lyarwood | bauzas: not that I have anything for today but we have a few things this cycle | |
| 16:25:07 | bauzas | any stuff to raise ? | |
| 16:25:08 | bauzas | kk | |
| 16:25:27 | bauzas | #info lyarwood to chair the libvirt subteam by now | |
| 16:25:43 | bauzas | lyarwood: thanks for offering your name | |
| 16:25:55 | artom | Don't take it in vain now | |
| 16:26:03 | bauzas | #topic Open discussion | |
| 16:26:10 | bauzas | one last paperwork bit | |
| 16:26:14 | bauzas | (gibi): release liaison role | |
| 16:26:22 | gibi | so | |
| 16:26:38 | gibi | bauzas: is now the PTL and the release liaison as well | |
| 16:26:42 | gibi | which is suboptimal | |
| 16:26:52 | bauzas | which means I'm also a bottleneck now | |
| 16:26:53 | gibi | do we have a volunteer to take that role over? | |
| 16:27:11 | gibi | it is not hard, you will get cc-d to release proposal patches to check and approve | |
| 16:27:19 | bauzas | tbc, the release liaison role is about reviewing patches from the release team | |
| 16:27:46 | bauzas | until either the PTL or the release liaison approves the patch, it can't land | |
| 16:28:03 | sean-k-mooney | i mean i can do it if no one else wants too i really dont mind | |
| 16:28:06 | bauzas | example https://review.opendev.org/c/openstack/releases/+/808706 | |
| 16:28:44 | sean-k-mooney | i keep an eye on the os-vif ones anyway but someone on the stable team might make more sense | |
| 16:28:52 | bauzas | sean-k-mooney: appreciated | |
| 16:29:19 | bauzas | I'll make the changes in the appropriate repo so you'd get automatically CC'd | |
| 16:29:29 | gibi | sean-k-mooney: thank you | |
| 16:29:53 | sean-k-mooney | no worries | |
| 16:29:58 | elodilles | well, as I also a release core and also propose nova releases lately it would be weird to propose and approve my own patches and then +W o:) | |
| 16:30:36 | bauzas | elodilles: heh, depending whether you're schizophrenic, this could work | |
| 16:30:47 | elodilles | :D | |
| 16:31:17 | bauzas | ok, moving on | |
| 16:31:22 | bauzas | sean-k-mooney: thanks again | |
| 16:31:38 | bauzas | now the big discussion | |
| 16:31:47 | bauzas | pasting the whole section | |
| 16:31:49 | bauzas | (gibi): gathering opinions about the current lower-constraints failure. | |
| 16:31:56 | bauzas | bottom line: on stable branches we are installing tox which installs virtualenv which bundles setuptools unconstrained. This now leads to that we cannot install decorator 3.4.0 on stable any more as it depends on "user_2to3" from setuptools but the recent setuptools 58.0 removed support for that. | |
| 16:32:02 | bauzas | Options to resolve the situation bump decorator major version from 3.4.0 to 4.0.0 on stable branches. Does it against stable policy? pin virtualenv version on stable during tox install disable lower-constraints testing | |
| 16:32:14 | bauzas | shit, I pasted wrong | |
| 16:32:20 | bauzas | gibi: your turn | |
| 16:32:27 | gibi | let me untangle that | |
| 16:32:27 | bauzas | explain the 3 options | |
| 16:32:50 | gibi | so option 1) bump major version of decorator from 3.4 to 4.0 on stable. Is it allowed on stable? | |
| 16:33:01 | gibi | option 2) pin virtualenv during tox install | |
| 16:33:11 | gibi | option 3) disable lower-constraints job | |
| 16:33:28 | gibi | I personally think that using unconstrained setuptools on stable is dangerous | |
| 16:33:36 | gibi | so I would go with 2) long turn | |
| 16:33:39 | gibi | term | |
| 16:33:53 | lyarwood | Agreed, 2 would be my choice | |
| 16:33:53 | artom | Yeah, seems like 2 is the safest... what's the danger with it? Is there a catch? | |
| 16:33:57 | bauzas | gibi: let's explain which stable branches again are impacted | |
| 16:34:13 | bauzas | you already told but this doesn't harm to tell again | |
| 16:34:14 | gibi | so in nova we are impacted stable/ussuri and older | |
| 16:34:16 | sean-k-mooney | gibi: technially i dont think we are allowe to bump miniums on stable on the other hand we already did it a while ago for the inital lower constraitnts fix | |
| 16:34:26 | gibi | on placement we are impacted on master but the fix has been landed | |
| 16:34:40 | gibi | on stable/xena we could release RC2 with the bump | |
| 16:34:47 | elodilles | I also like option 2, and actually found some (abandoned) trial from the past that was similar https://review.opendev.org/q/topic:constrain-tox-install | |
| 16:34:50 | gibi | but on stable/wallaby and back the same quertion applies | |
| 16:35:12 | sean-k-mooney | from a disto point of view 2 is not great | |
| 16:35:22 | sean-k-mooney | since they cannot pin them the same way | |
| 16:35:25 | bauzas | option 1 has a question I can't answer | |
| 16:35:32 | sean-k-mooney | but most distros also dont use lower constratints | |
| 16:35:33 | gibi | does LTS distros use unconstrained setuptools as well? | |
| 16:35:54 | bauzas | can we deliver a .y release by bumping the decorator dependency without breaking the semver rules ? | |
| 16:36:07 | sean-k-mooney | rhel ignored the upper and lower constraitnts | |
| 16:36:14 | sean-k-mooney | debian used to look at lower | |
| 16:36:25 | sean-k-mooney | ubunut used to look at upper | |
| 16:36:46 | sean-k-mooney | we can try 2 but i feel like we are going to end up with 3 | |
| 16:37:00 | gibi | sean-k-mooney: sure we could end up with 3 for different reasons :) | |
| 16:37:12 | artom | So 2 for distros means "maintain this old version of virtualenv in your repos", right? | |
| 16:37:22 | elodilles | bauzas: I think we can, but it's probably not fortunate. semver says that req changes needs MINOR / .y version bump | |