Earlier  
Posted Nick Remark
#openstack-nova - 2023-11-08
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 bauzas anyway, I should stop arguing here as it's useless, I should rather invest time in the python community itself
09:58:47 sean-k-mooney i mean we dont supprot or release for 2 years
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
10:43:23 jrosser ah thats interesting, thanks
10:43:46 bauzas jrosser: fwiw, please know that you could be hit with https://bugs.launchpad.net/nova/+bug/2041519 if you use A100
10:44:17 bauzas jrosser: and yeah, I send hugs to you about vGPU GRID16 EOL support for AI
10:44:42 jrosser bauzas: yeah i saw that discussion the other day - the whole thing is a total disaster /o\
10:44:50 bauzas you now need to buy a fancy expensive AIE license : https://docs.nvidia.com/ai-enterprise/4.0/release-notes/index.html
10:45:04 jrosser indeed, for 50 to 100% of the cost of the hardware

Earlier   Later