| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-04 | |||
| 16:28:45 | elodilles | well, the transition date is April 20th | |
| 16:29:02 | elodilles | should be good to release earlier though | |
| 16:29:05 | bauzas | ok, then we'll track the progress every week | |
| 16:29:16 | bauzas | and every week, I'll ask the question | |
| 16:29:26 | elodilles | maybe we can see if next week we can cut a release | |
| 16:29:35 | bauzas | in the meantime, people can merge whatever they want | |
| 16:29:40 | bauzas | elodilles: yup | |
| 16:29:51 | bauzas | don't disagree | |
| 16:30:14 | elodilles | note also, that we had a xena release around end of january (24.2.0) | |
| 16:30:29 | bauzas | #link https://etherpad.opendev.org/p/nova-stable-xena-em Tracking etherpad for Xena | |
| 16:30:31 | elodilles | so really the open patches is mostly the ones that we need to consider | |
| 16:31:05 | bauzas | #info please tell the nova community which patches you want to have to be released before next week by pinging bauzas on IRC | |
| 16:31:05 | sean-k-mooney | bauzas: i have approved the mdev patch | |
| 16:31:11 | sean-k-mooney | just skimin gthe open ones now | |
| 16:31:18 | bauzas | cool thanks | |
| 16:31:29 | bauzas | anyway, elodilles, add your points now | |
| 16:31:30 | elodilles | ++ | |
| 16:31:50 | elodilles | well, there is nothing left just the usual | |
| 16:31:53 | elodilles | #info stable gates seem to be OK - though it's hard to merge patches due to intermittent failures | |
| 16:31:58 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:33:23 | bauzas | cool | |
| 16:33:37 | bauzas | last topic then | |
| 16:33:42 | bauzas | #topic Open discussion | |
| 16:33:45 | bauzas | the agenda is empty | |
| 16:33:53 | auniyal | so I was looking for backports in 2023.1, zed and yoga | |
| 16:33:55 | bauzas | anyone wants to discuss about something that we missed at the PTG ? | |
| 16:34:51 | gibi | bauzas: the lower constraint job discussion was punted last week | |
| 16:35:31 | bauzas | gibi: yup, I haven't asked you if you wanted to discuss about it today | |
| 16:35:32 | gibi | bauzas: I have not much to add to what was in the current or in the previous PTG etherpad just that I have the intention to add a limited lower constraint job | |
| 16:35:36 | bauzas | gibi: do you want now ? | |
| 16:35:40 | gibi | we can | |
| 16:35:44 | bauzas | cool | |
| 16:36:05 | bauzas | (we also have other punted topics, but again, those were not prioritary for this week) | |
| 16:36:16 | bauzas | gibi: so, shoot | |
| 16:36:18 | gibi | yeah, this is not priority either | |
| 16:36:36 | bauzas | we discussed your topic briefly | |
| 16:36:50 | bauzas | concerns were coming from any potential transitive dependencies and the scope | |
| 16:37:01 | gibi | so I see that sean-k-mooney prefer not to have it | |
| 16:37:04 | bauzas | we said this was for unittests and functionaltests | |
| 16:37:11 | gibi | so the scope is intentionally limited | |
| 16:37:11 | dansmith | gmann also had comments I think | |
| 16:37:25 | bauzas | correct | |
| 16:37:30 | sean-k-mooney | i do not wnat nova to be the only ones to have it if we do i would prefer it to be a perodic | |
| 16:37:35 | gibi | so run unit and functional test, only with the some of our direct depds pinned to lowest | |
| 16:37:43 | bauzas | and if I'm not wrong, this wouldn't be having transitive deps in the filez | |
| 16:37:45 | bauzas | file | |
| 16:37:54 | gibi | no transitives yes | |
| 16:38:02 | sean-k-mooney | im more or less ok with that but limitation | |
| 16:38:04 | bauzas | ok, then I wasn't wrong | |
| 16:38:06 | dansmith | I didn't hear the pitch about why we should, but I too am a bit skeptical | |
| 16:38:23 | bauzas | dansmith: it was due to a regression we had with os-traits | |
| 16:38:33 | gibi | dansmith: in Zed we released nova code that depended on os-traits versions but we forgot to bump the version | |
| 16:38:33 | bauzas | we modified the code by using the new traits | |
| 16:38:38 | gmann | gibi: did you try how it will run with nova as lower bound and other deps's deps as upper bound ? | |
| 16:38:40 | bauzas | that yeah | |
| 16:38:59 | gibi | gmann: not yet, I had some local trials but mostly got sidetracked | |
| 16:39:07 | gmann | I am ok to run unit test lower bound job but just wondering how complex it will be to setup and keep green | |
| 16:39:11 | dansmith | traits is kinda weird though right? we sort of always need that to move in lockstep with our usage of it yeah/ | |
| 16:39:16 | gmann | gibi: ack | |
| 16:39:29 | dansmith | so requirements and the lower constraint is always the same? | |
| 16:39:49 | dansmith | it's not like libvirt where we actually want to support a range of older and newer versions | |
| 16:40:14 | gibi | dansmith: yeah, in case of os-traits we have a fairly hard connection | |
| 16:40:15 | gmann | I think we need to keep lower constraint file as requirements.txt constraints might be higher than lowest supported versions | |
| 16:40:32 | dansmith | so was the miss that we always get the latest os-traits from other stuff and we didn't notice we needed a bump? | |
| 16:40:33 | sean-k-mooney | gmann: they should not be | |
| 16:40:36 | gmann | or gibi you want to test what we have in requirements.txt as lower bound and not actual lower bound ? | |
| 16:40:39 | gibi | gmann: I thought that the minimum in requiremenets.txt is the lowest we need to test with | |
| 16:40:44 | gmann | ok | |
| 16:40:48 | sean-k-mooney | requirements has our lower bound | |
| 16:41:11 | sean-k-mooney | while lower version might work if you dont use all features | |
| 16:41:27 | gmann | sean-k-mooney: yeah but they are no guaranteed to be lowest bound, we can have b>8 where it might work b==6 also | |
| 16:41:28 | gibi | dansmith: os-vif is a bit softer, i.e. lower != higher, but we can break the dep the same way | |
| 16:41:29 | dansmith | that's true of libvirt but probably less so os-traits | |
| 16:41:54 | sean-k-mooney | gmann: if you use somthing older then in in requiremtns i would say thats an unsupported config | |
| 16:42:03 | dansmith | so is the proposal to maintain a separate list, or to sed the >= out of requirements.txt? | |
| 16:42:14 | bauzas | do people say we shall pin our versions in reqs.txt ? | |
| 16:42:23 | gmann | that is why there are two things 1. test what we have lower bound in requirements.txt 2. test actual lower(st) bound work for nova | |
| 16:42:26 | gibi | dansmith: basically sedding the requirements.txt | |
| 16:42:50 | sean-k-mooney | we dont want to do 2 | |
| 16:42:50 | dansmith | gibi: okay if it's that, and periodic, then I'm okay with it.. what I don't want is a second list and pre-merge testing (just because of the load) | |
| 16:42:52 | bauzas | hah | |
| 16:43:04 | bauzas | so, s/>=/== then ? | |
| 16:43:07 | sean-k-mooney | we could do 1 | |
| 16:43:08 | gibi | dansmith: ack, I'm OK to make it periodic | |
| 16:43:10 | bauzas | automatically from reqs.txt ? | |
| 16:43:10 | gmann | yeah, doing 2 is difficult | |
| 16:43:20 | sean-k-mooney | i would say 2 is a non goal | |
| 16:43:20 | dansmith | bauzas: yeah, I think that's reasonable | |
| 16:43:22 | gibi | bauzas: that is the idea | |
| 16:43:28 | gmann | I am ok to doing 1 and even in check pipeline as unit test also ok | |
| 16:43:34 | gmann | sean-k-mooney: yes | |
| 16:43:41 | bauzas | so a specific tox target ? | |
| 16:43:55 | gibi | bauzas: yepp | |
| 16:43:59 | bauzas | to -epy38-min ? | |
| 16:44:00 | gmann | yeah, that will be helpful to check locally also | |
| 16:44:12 | bauzas | ok, then I don't disagree the idea | |
| 16:44:16 | dansmith | a specific tox target that runs both in a single go would be nice to avoid needing separate unit/functional jobs yeah | |
| 16:44:22 | bauzas | I see | |
| 16:44:38 | dansmith | and I'd prefer periodic until/unless we see it breaking more often | |
| 16:44:39 | gibi | sean-k-mooney, gmann : I agree to aim for 1. If somebody want to find the real lower bound (i.e 2) then that person can play with the requirements.txt and with the new job | |