| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 09:50:58 | bauzas | sean-k-mooney: sure I'm not debating your own changes, I'm rather arguing about pyproject.toml instead | |
| 09:51:06 | sean-k-mooney | zigo: this will eventually affect all distos not just centos so im trying to get ahead of it by enausering we have basic supprot for pep 517/518/660 | |
| 09:51:31 | bauzas | sean-k-mooney: I'm basically hating what the python community did for packaging, ie. creating yet another standard | |
| 09:51:37 | sean-k-mooney | zigo: we are goign to continue to use reqiurements.txt | |
| 09:51:54 | zigo | sean-k-mooney: Guess which distro will be affected first ... :/ | |
| 09:52:07 | sean-k-mooney | zigo: its actully centos not debian | |
| 09:52:36 | sean-k-mooney | well depending on how you look at it. im usign debian sid right now and its works fine without this | |
| 09:52:40 | sean-k-mooney | for now | |
| 09:52:41 | zigo | Well, it's not like if I was maintaining 400+ python packages for OpenStack that will all need patching ... :/ | |
| 09:53:06 | bauzas | zigo: yeah, thanks the python community for that brilliant idea | |
| 09:53:56 | sean-k-mooney | bauzas: you know it annoys me every time you do that right | |
| 09:54:16 | sean-k-mooney | bauzas: your being dilberatly dismissive of there efforts to solve an issue that many of there users had | |
| 09:54:42 | zigo | On the bright side, I very much agree that the setup.py thingy was a disaster, ie: having to execute code to be able to find out things instead of reading a configuration file was kind of a very broken idea. | |
| 09:55:01 | sean-k-mooney | zigo: ya i really dont like impertive systems for packaging | |
| 09:55:26 | sean-k-mooney | not that debina or rpm format get it correct either | |
| 09:55:27 | zigo | Though there a better ways than breaking everyone at once... | |
| 09:56:00 | sean-k-mooney | i dont know 2 years of deprecation after several years of supprot is kind of reasonsble | |
| 09:56:15 | sean-k-mooney | and to be clear the only thing that broke for us | |
| 09:56:27 | bauzas | 2 years is a very short timeframe IMHO | |
| 09:56:28 | sean-k-mooney | is an extention to setuptools we have in pbr | |
| 09:56:35 | zigo | I agree with Sylvain. | |
| 09:56:41 | sean-k-mooney | if we used plain setuptools with no extentiosn we would not ahve been broken at all | |
| 09:56:44 | bauzas | sean-k-mooney: fwiw, I +2'd the change itself | |
| 09:56:57 | bauzas | that's not because I hate that direction that I'll hold it | |
| 09:57:03 | zigo | There are thousands of upstream of python modules that will *NOT* be reactive enough. | |
| 09:57:05 | bauzas | the ship sailed and I need to move on | |
| 09:57:25 | sean-k-mooney | bauzas: ack, we needed to wait for pbr 6.0.0 for the py 39 job to pass, that was released 7 hours ago so we will see what the ci says when it completes | |
| 09:57:41 | bauzas | but I'm just throwing my hate by explaining why I think 2 years is not a respectful timeframe | |
| 09:57:59 | sean-k-mooney | zigo: right but thats why they implemetned a fallback that will work for vaniall setuptools out of the box | |
| 09:58:02 | bauzas | but that's not the first time the python community is trampling us | |
| 09:58:47 | sean-k-mooney | i mean we dont supprot or release for 2 years | |
| 09:58:47 | bauzas | anyway, I should stop arguing here as it's useless, I should rather invest time in the python community itself | |
| 09:58:54 | sean-k-mooney | we only supprot them for 18 months | |
| 09:58:57 | sean-k-mooney | offically anyway | |
| 09:59:11 | sean-k-mooney | so your holding them ot a higher standard then we hold ourselves? | |
| 10:00:15 | zigo | BTW, Python 3.12 thingy will start in Unstable next November. | |
| 10:00:24 | zigo | Expect bug reports and patches from me ... | |
| 10:00:33 | bauzas | I have the opinion that the lower you're a dependency, the longer you need to keep support | |
| 10:00:44 | zigo | Yet another thing: how come every single new version breaks my world ... | |
| 10:00:51 | sean-k-mooney | next november as in 2025 or as in that then next thing to start in novemerb on your backlog | |
| 10:01:00 | bauzas | and a language sounds to me like probably one of the lowest dependencies we have and the most commonly shared | |
| 10:01:04 | zigo | Oh sorry, as in this month ! | |
| 10:01:10 | sean-k-mooney | ok :) | |
| 10:01:27 | sean-k-mooney | i was like that seams far off | |
| 10:01:44 | zigo | 3.14 is planned for Trixie (ie: debian 13). | |
| 10:01:45 | bauzas | forcing people to upgrade by 2 years if you're a very common library is kinda harsh | |
| 10:02:16 | sean-k-mooney | bauzas: your only forced to upgrade if you dont pin your deps | |
| 10:02:35 | sean-k-mooney | you can always you an older pip to get the old behavior | |
| 10:02:44 | sean-k-mooney | bauzas: the reason that is not viabel for us | |
| 10:03:12 | sean-k-mooney | is openvswitch now requried pep 517 to build in debian and newer releases then we ship in centos/ubuntu | |
| 10:03:29 | bauzas | that's my point | |
| 10:03:33 | sean-k-mooney | so pining pip breaks once you have a new enought ovs | |
| 10:03:44 | bauzas | if this wasn't ovs, this would be something else | |
| 10:04:03 | bauzas | since lots of projects are moving on their own timeframe, the other ones also need to adjusty | |
| 10:04:20 | sean-k-mooney | well the ovs issue is they did not keep supprot for both like i am | |
| 10:04:39 | sean-k-mooney | im just adding pyproject.toml supprot without removing setup.py support | |
| 10:04:49 | sean-k-mooney | zigo: ^ important point for you | |
| 10:04:56 | bauzas | sean-k-mooney: yeah, hence my +2 | |
| 10:05:08 | bauzas | we're continuing to do the old way but we allow doing it the new way | |
| 10:05:14 | sean-k-mooney | we can drop setup.py support in the future but its not breaking anything so i didnt see a point | |
| 10:05:17 | zigo | sean-k-mooney: Yeah, I'll look at what you did! | |
| 10:05:19 | bauzas | again, my rant wasn't directed to your change | |
| 10:05:52 | sean-k-mooney | bauzas: i know | |
| 10:06:12 | sean-k-mooney | i just feel like i have to play devels avocate and defend the python core team | |
| 10:13:45 | jrosser | talking of gpu company starting with n, A100/A30 removal from the vGPU driver v16 is causing us a massive headache right now | |
| 10:14:03 | sean-k-mooney | jrosser: yep... | |
| 10:14:05 | jrosser | anyone with ideas what to do would be interesting | |
| 10:14:28 | sean-k-mooney | other then keepign the old driver and pinnign your kernel till you retire the hardware | |
| 10:14:34 | sean-k-mooney | there isnt much you can do | |
| 10:14:47 | sean-k-mooney | jrosser: what os are you on | |
| 10:14:54 | jrosser | ubuntu | |
| 10:15:18 | sean-k-mooney | cool well i think you can continue to use the 15.x driver for the lifetime of 22.04 right | |
| 10:15:31 | sean-k-mooney | although obviorulsy wihtout any future security/preformance improvements | |
| 10:15:44 | jrosser | i don't believe we are going to be able to get any more vCS licences once ours expire | |
| 10:16:22 | sean-k-mooney | oh right the lisciense have an experation date... | |
| 10:16:31 | jrosser | yup | |
| 10:16:45 | sean-k-mooney | they have a diffent driver that the created for some of there skus | |
| 10:16:53 | sean-k-mooney | do you know fi the a100 moved to the new dirver | |
| 10:17:21 | sean-k-mooney | they are spliting there product skus between enterpirse and ai/ml usecases i belive | |
| 10:18:28 | sean-k-mooney | i havent really looked at the detail but i know the grid driver is being split in two for two diffent classes of hardware/workloads but i dont knwo where the a100 lands in that regard | |
| 10:30:57 | jrosser | sean-k-mooney: we have been attempting to PCI passthrough the MIG sriov VF (this might be pointless and never work, but it is at the advice of someone from nv) and get this https://paste.opendev.org/show/bTDDSu1EaNMhflc12ROB/ - do you see anything like that before with PCI passthrough? | |
| 10:32:57 | sean-k-mooney | jrosser: my understanding is while that could work the nvida driver in the guest does not curretnly work on the vf | |
| 10:33:17 | jrosser | i could totally believe that | |
| 10:33:46 | sean-k-mooney | header type 127 does seam famialr for some reason | |
| 10:34:08 | sean-k-mooney | i belive its one fo the extended pci capablity headers | |
| 10:34:09 | jrosser | and that certainly the case for vGPU/GRID driver on the host and free DataCenter driver in the guest which would be the most obvious licencing bypass you could do, so I expect that not to work | |
| 10:34:32 | jrosser | the advice we got was to try DataCenter driver on the host and in the guest | |
| 10:35:10 | sean-k-mooney | https://forum.level1techs.com/t/unknown-pci-header-type-127-for-device-000000-0/180125/4 | |
| 10:35:27 | sean-k-mooney | appreently its somethign to do with the graphsics card sleep modes | |
| 10:35:46 | opendevreview | Merged openstack/nova-specs master: Re-propose spec for ephemeral storage encryption https://review.opendev.org/c/openstack/nova-specs/+/897502 | |
| 10:35:48 | opendevreview | Merged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt https://review.opendev.org/c/openstack/nova-specs/+/897503 | |
| 10:37:13 | sean-k-mooney | jrosser: so its apprently because the card is not reseting properly when attached/detached form the vm | |
| 10:37:41 | sean-k-mooney | jrosser: thats a pretty common thing on consumer graphics cards that are pci passhtough to a vm | |
| 10:37:47 | jrosser | hmm | |
| 10:38:09 | sean-k-mooney | im suprised thats a problem for a100 but since they never intended the vfs to be passed to the guest its not that surprising | |
| 10:41:03 | sean-k-mooney | https://forum.level1techs.com/t/solved-gpu-passthrough-suddently-stopped-working-on-windows-10-vm/171273/5 | |
| 10:41:42 | sean-k-mooney | i have not tired this but apprently you can disbable the d3 idel state for that device | |
| 10:41:43 | sean-k-mooney | options vfio-pci ids=10de:2486,10de:228b disable_vga=1 disable_idle_d3=1 | |
| 10:42:24 | opendevreview | Merged openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Caracal https://review.opendev.org/c/openstack/nova-specs/+/898319 | |
| 10:42:51 | sean-k-mooney | jrosser: if it is just a sleep issue i woudl give that a try for the mig vfs | |