| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-25 | |||
| 13:17:27 | gibi | I agree with sean-k-mooney not to blindly alter our test process by pinning requirements. I suggest to try to find the offending dependency and try to figure out what makes it hard for pip to resolve the deps | |
| 13:17:33 | sean-k-mooney | if we were to fix this in nova we woudl have to delete and recreate the pinned deps every time we run tox | |
| 13:17:53 | kashyap | sean-k-mooney: I wouldn't be too quick to dismiss the fix without actually looking at the problem and properly understanding it. | |
| 13:17:59 | sean-k-mooney | and we would have to ensure that pip-compile follows UC and test-requirement properly | |
| 13:18:22 | kashyap | gibi: Yeah, I think I should have a trace of one of the offending deps ... lemme check | |
| 13:18:26 | sean-k-mooney | kashyap: im not im pointing out that they probaly dont fully understand how we test and what | |
| 13:18:39 | sean-k-mooney | we require form a pti point of view | |
| 13:18:56 | sean-k-mooney | so we need to actully see if its pti compleint and test wat we want ti to test | |
| 13:19:00 | kashyap | sean-k-mooney: Ah, sure. I don't deny that. (Aside, what is "pti"?) | |
| 13:19:10 | sean-k-mooney | project testing interface | |
| 13:19:54 | sean-k-mooney | kashyap: https://github.com/openstack/governance/blob/master/reference/pti/python.rst specificly | |
| 13:20:10 | kashyap | gibi: E.g. for me it got stuck at this "decorator" thing: https://paste.opendev.org/show/baNIMuM5YxlBA8nwxm10/ | |
| 13:20:11 | sean-k-mooney | defien how all offical python project must do there testing | |
| 13:20:40 | sean-k-mooney | kashyap: it likely will not be stable in all caes | |
| 13:21:02 | sean-k-mooney | basicaly as release happen you might see that change | |
| 13:21:09 | gibi | kashyap: so the next step would be to compare the pip run on f35/36 with a non-stuck pip run on ubuntu 2004 | |
| 13:21:25 | gibi | maybe with a run from our gate | |
| 13:21:26 | sean-k-mooney | its porbaly python3.10 vs 3.9 really | |
| 13:21:35 | kashyap | gibi: But it's also non-deterministic for me; "eventually" it went ahead and succeeded | |
| 13:21:53 | kashyap | sean-k-mooney: You're using 3.9? | |
| 13:21:58 | gibi | sean-k-mooney: stilly p310 not stuck on my debian | |
| 13:21:58 | sean-k-mooney | the odd thing is im pretty sure it work for me on 3.9 and 3.10 | |
| 13:22:13 | sean-k-mooney | ya i think 3.10 worked for me too | |
| 13:22:23 | sean-k-mooney | kashyap: i have 3.8 3.9 and 3.10 | |
| 13:22:35 | gibi | so this can be pip cache (need a clean VM to reproduce) already globally installed python deps | |
| 13:22:40 | sean-k-mooney | i normlaly use 3.8 since its supported on the most set of branches | |
| 13:22:40 | kashyap | (I'm using 3.10 too; FWIW) | |
| 13:22:57 | sean-k-mooney | kashyap: just so you know 3.10 is not supported yet | |
| 13:23:09 | sean-k-mooney | as in its experimental for zed | |
| 13:23:32 | sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/zed.rst#python-runtimes-for-zed= | |
| 13:23:44 | kashyap | gibi: sean-k-mooney: Sorry, I was lying! I was using 3.8.13, actually | |
| 13:24:02 | sean-k-mooney | so its nice that you are using it but we do not expect it to work in all cases. | |
| 13:24:11 | sean-k-mooney | kashyap: you are gettign that failure on 3.8 | |
| 13:24:16 | kashyap | Yep | |
| 13:24:22 | sean-k-mooney | hum maybe its related to the distro packages then | |
| 13:24:28 | kashyap | It's not deterministic. So I don't want to take your time much on it. | |
| 13:24:28 | sean-k-mooney | our your pip version | |
| 13:24:35 | sean-k-mooney | what version of pip have you installed | |
| 13:24:51 | kashyap | sean-k-mooney: It's in a tox env. And I'm using "pip 22.1.1" | |
| 13:25:33 | kashyap | But for now, it's "magically resolved" after a couple of runs. I haven't even recreated 3.8 tox env. | |
| 13:25:46 | sean-k-mooney | pip 22.0.4 from /home/sean/repos/openstack/nova/.tox/py3/lib/python3.10/site-packages/pip (python 3.10) | |
| 13:26:22 | sean-k-mooney | it could be reelated to the version of setuptool/pip that is bundeled in vitrualenv | |
| 13:26:38 | sean-k-mooney | that is where the version used by tox come form by default | |
| 13:26:56 | sean-k-mooney | i belive you can specify the version when creating the tox env | |
| 13:27:18 | opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | |
| 13:30:55 | sean-k-mooney | you might be able to pass tox -e py3 --force-dep pip\<22.1 | |
| 13:31:07 | sean-k-mooney | kashyap: can you try ^ | |
| 13:31:47 | sean-k-mooney | there is also a plugin for this apprently https://pypi.org/project/tox-pip-version/ but dont know if it work but it would be interesting to see if that helps | |
| 13:32:05 | sean-k-mooney | kashyap: do you install tox form pypi by the way | |
| 13:32:10 | kashyap | sean-k-mooney: Is that verbatim syntax correct? "\<" | |
| 13:32:12 | sean-k-mooney | or are you using it form fedora | |
| 13:32:23 | sean-k-mooney | \< was to escape the < | |
| 13:32:33 | sean-k-mooney | so it shoudl be pip<22.1 | |
| 13:32:46 | sean-k-mooney | but i think you need to escape it on a bash cli | |
| 13:33:09 | kashyap | In this case both versions are same: 3.25. And I've used 'tox' from system in this case | |
| 13:33:39 | sean-k-mooney | ok i always use it form pypi to normalise behavior between the distors im using | |
| 13:34:14 | kashyap | sean-k-mooney: Also, did you mean "py3" there? | |
| 13:34:22 | sean-k-mooney | yes | |
| 13:34:31 | sean-k-mooney | py3 uses your default python 3 | |
| 13:34:44 | sean-k-mooney | so i use that to not have to care which python3 that is | |
| 13:34:55 | kashyap | Nod; /me tries | |
| 13:36:27 | kashyap | python-dep-hell-- | |
| 13:36:54 | sean-k-mooney | hehe well this seams to be disto specific so not sure its entirly fair | |
| 13:37:05 | sean-k-mooney | at least its not nodejs | |
| 13:37:15 | sean-k-mooney | npm is just awfull | |
| 13:37:42 | sean-k-mooney | its like javascript libs compeet to see how many other libs they can use before they create a cycle | |
| 13:38:00 | dansmith | the js community is insane :) | |
| 13:38:19 | dansmith | I've never had problems resolving deps with npm, but probably just haven't done it enough | |
| 13:38:23 | kashyap | sean-k-mooney: Still, I hate this system pkgs vs PyPi interaction hell. It's been behind me for years; I keep hoping it gets better :D | |
| 13:38:36 | kashyap | dansmith: You're a brave man; this chanel is recorded, you know that, right :D | |
| 13:38:45 | sean-k-mooney | dansmith: depresovling is fine but packaging that as a distro is just not really possible | |
| 13:38:59 | dansmith | kashyap: I think they know they have a problem :) | |
| 13:39:10 | dansmith | sean-k-mooney: yeah totally | |
| 13:39:46 | sean-k-mooney | honestly the best that disto can do is provde a way to install npm and then let it do the rest | |
| 13:40:02 | dansmith | yup and I kinda expect that's where we're headed with python too | |
| 13:40:22 | sean-k-mooney | ya perhaps. go too for what its worth | |
| 13:40:30 | dansmith | I'm sure | |
| 13:40:41 | sean-k-mooney | in the past lanauges did not have a packagem manager but now its the default for them too | |
| 13:41:09 | sean-k-mooney | they had been always thrid party in c/c++/java | |
| 13:42:18 | sean-k-mooney | it does make cve much harder to manage but on the other hand if you fix it in the "comunity/language" package manage you fix it for all distos that use that | |
| 13:42:46 | dansmith | it totally makes the security landscape a disaster, | |
| 13:43:07 | dansmith | but I think npm integrates vulnerability tagging with the package manager itself, which is probably good | |
| 13:46:41 | sean-k-mooney | kashyap: by the way if this is blocking you crrently you might want to use a podman contianer or vm temporaly to workaround it | |
| 13:46:58 | sean-k-mooney | you could also try the pip-compile approch | |
| 13:47:17 | kashyap | sean-k-mooney: It's not quite blocking me; but annoying. Right, for now I'm resorting to a clean container approach. I'll check 'pip-compile' later | |
| 13:47:19 | sean-k-mooney | and perphaps protoype a tox change | |
| 13:47:20 | kashyap | Thakns! | |
| 13:50:08 | kashyap | For now, I'm just not using Py3.10. I have a row of yaks to shave before I head out for the long PTO | |
| 13:50:26 | kashyap | Thx for your debugging help. | |
| 14:08:12 | erlon | Hi folks, can you please give a push on these 2 patches? They are clean cherry-picks and just need 1 mode +2: | |
| 14:08:12 | erlon | https://review.opendev.org/c/openstack/nova/+/836015 | |
| 14:08:12 | erlon | https://review.opendev.org/c/openstack/nova/+/838550/3 | |
| 14:12:35 | sean-k-mooney | bauzas: dansmith ^ can you take a look at those or add me/gibi to the stable group wand we can. the backport is valid in my view and melwitt is +2 on both | |
| 14:15:04 | sean-k-mooney | actully elodilles if you are about you might be abel to help with those stabel reviews | |
| 14:19:36 | elodilles | sean-k-mooney: looking | |
| 14:28:56 | elodilles | erlon: they look good to me, +2+W'd them | |
| 14:29:20 | erlon | elodilles: thanks! | |
| 14:29:32 | elodilles | erlon: thanks for proposing the backport! | |
| 14:35:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP: skeleton for asserting PCI resources in Placement https://review.opendev.org/c/openstack/nova/+/843291 | |
| 14:45:43 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146 | |