| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-04 | |||
| 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 | |
| 16:51:56 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-04-16.00.txt | |
| 16:51:56 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-04-16.00.log.html | |
| 16:51:56 | gibi | o/ | |
| 16:52:15 | elodilles | thanks o/ | |
| 16:53:47 | bauzas | that's also it for me today | |
| 16:53:50 | bauzas | see ya folks | |
| 16:54:21 | bauzas | for the fun, I want to test virtiofs on my laptop with a windows guest :) | |
| 16:57:31 | bauzas | waaah that works with winfcp | |
| 17:01:45 | dansmith | gibi: sean-k-mooney: can ya'll hit this at some point: https://review.opendev.org/c/openstack/nova/+/878238 | |
| 17:01:55 | dansmith | related to a recent conversation we had | |
| 17:04:16 | gibi | dansmith: added to my list | |
| 17:04:25 | dansmith | thanks | |
| 17:42:38 | opendevreview | Dan Smith proposed openstack/nova master: Add compute_id column to instances table https://review.opendev.org/c/openstack/nova/+/879499 | |
| 17:42:39 | opendevreview | Dan Smith proposed openstack/nova master: Add compute_id to Instance object https://review.opendev.org/c/openstack/nova/+/879500 | |
| 17:45:47 | dansmith | anyone else having trouble with the fast8 target? it's complaining about python not being in the list of allowed externals, presumably because of the install_command override | |
| 17:46:06 | dansmith | adding it causes it to fail install because it tries to install nova to my /usr/local instead of the venv | |
| 17:46:37 | dansmith | other targets don't seem to have any problems | |
| 17:48:11 | clarkb | python shouldn't be in externals because it is in the venv | |
| 17:48:25 | dansmith | I know that's how it should work | |
| 17:50:02 | dansmith | okay I blew away .tox and it may be working | |
| 17:50:35 | dansmith | I cleaned a(n apparently very old) .tox/fast8 before and it didn't fix it, but I think because flake8 now uses .tox/shared | |
| 17:50:41 | dansmith | so removing that seems to have fixed it up | |
| 17:51:05 | dansmith | I dunno how it got confused about that, but it was the python pip install on the nova package that it was failing with that error | |
| 17:51:14 | dansmith | so maybe something to do with me recently upgrading to py311 on my system | |
| 17:51:28 | dansmith | yeah, that worked | |
| 17:54:13 | dansmith | the pep8 target worked, but I guess it doesn't use the shared venv so I guess it got rebuilt and the one fast8 uses didn't trigger it or soemthing | |