| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-04 | |||
| 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 | dansmith | gmann also had comments I think | |
| 16:37:11 | gibi | so the scope is intentionally limited | |
| 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 | bauzas | we modified the code by using the new 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: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 | 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:50 | sean-k-mooney | we dont want to do 2 | |
| 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 | gmann | yeah, doing 2 is difficult | |
| 16:43:10 | bauzas | automatically from reqs.txt ? | |
| 16:43:20 | dansmith | bauzas: yeah, I think that's reasonable | |
| 16:43:20 | sean-k-mooney | i would say 2 is a non goal | |
| 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 | |
| 16:44:42 | bauzas | so the tox target would call out a script that would copy/sed reqs.txt by pinning to the mins | |
| 16:45:09 | gmann | gibi: agree | |
| 16:45:17 | gibi | bauzas: yeah | |
| 16:45:36 | bauzas | and the gate would periodically run a job that would call this target | |
| 16:45:42 | bauzas | then I don't disagree | |
| 16:45:46 | gibi | cool | |
| 16:45:51 | gibi | I see an agreement forming :) | |
| 16:45:52 | bauzas | anyone having concerns ? | |
| 16:46:05 | gibi | (now I need to find the time to do the scripting) | |
| 16:46:17 | bauzas | say it now or forever hold your peace | |
| 16:46:34 | bauzas | crickets, all cool | |
| 16:46:38 | gibi | thanks | |
| 16:46:44 | gibi | and sorry again for missing the firday sessions | |
| 16:46:51 | gibi | Friday even | |
| 16:47:12 | bauzas | #agreed gibi to work on a new tox target that would run unittests with a pinned min version of reqs.txt, with a periodic job testing it weekly | |
| 16:47:53 | bauzas | gibi: I guess you may want to do it as well for functional tests but this doesn't harm to me | |
| 16:48:14 | gibi | bauzas: yeah, lets see the unit first, adding functional to it is easy then | |
| 16:48:24 | bauzas | cool | |
| 16:48:31 | bauzas | I think dust is settled now | |
| 16:48:43 | bauzas | anything else before I call it a wrap ? | |
| 16:48:47 | auniyal | bauzas, I dont have anything w.r.t PTG missing item, can we discuss few backports ? | |
| 16:48:55 | gibi | I've updated the etherpad with the link to this meeting log | |
| 16:49:10 | bauzas | gibi: excellent for tracking decisions | |
| 16:49:27 | bauzas | auniyal: are you asking for specific change reviews ? | |
| 16:49:36 | auniyal | I have few backports which can be merged mostly for zed and yoga, I have reviewed them from my end, I would like to request cores to review them | |
| 16:49:46 | bauzas | if so, I'd prefer if you could ping folks off the meeting | |
| 16:50:04 | bauzas | (we generally try to avoid review requests during the meeting, for obvious reasons) | |
| 16:50:09 | auniyal | okay | |
| 16:50:23 | bauzas | (the main one is brevity) | |
| 16:50:37 | bauzas | ok, so, last call ? | |
| 16:51:51 | bauzas | thanks all | |
| 16:51:56 | bauzas | #endmeeting | |
| 16:51:56 | opendevmeet | Meeting ended Tue Apr 4 16:51:56 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:51:56 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-04-16.00.html | |