Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-31
17:29:47 dansmith I was hoping to have tested the migration allocation thing for real last week but ran out of time. Luckily my monday morning meeting was canceled I could get a jump on it
17:46:34 ivveh sean-k-mooney: add <iothreads/>
17:48:06 ivveh (as i couldn't find it anywhere in the extraspecs or other methods of modifying the xml) but feel free to point me in the correct direcion if iothreads do exist, i need to point them out and pin on them, maybe some other stuff too
17:49:01 sean-k-mooney its not currently supproted. we had a blueprint to add it a year ago but the person working on it did actuly push any code
17:49:30 ivveh gotcha, would it be as an extraspec or some other method?
17:50:03 sean-k-mooney what i was suggeting was to allway allcoate 1 and make it float over the cpu_share_set
17:50:37 sean-k-mooney we discussed if we shoudl supprot more then one but the advice form our virt team was no
17:51:23 sean-k-mooney they suggested that in the future 1 per cinder volume might make sense but the high level degisn we had dicussed in teh past was 1 keep it simple and start with all vms having 1 iothread
17:51:38 sean-k-mooney 2 in the future add a flavor extra spec to opt into one per cinder volum eif needed
17:52:09 sean-k-mooney 3 possible allow this to be set on the image or config instead (TBD if/when we add the 1 per cinder volume feature)
17:52:49 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/939254 is the most recent attempt
17:53:03 sean-k-mooney https://blueprints.launchpad.net/nova/+spec/iothreads-for-instances
17:53:19 ivveh thanks, ill have a look
17:53:37 sean-k-mooney this version is adding a config option to contol the behvior
17:54:31 sean-k-mooney ah the blueprint has the link to the ptg dicssion form last cyle https://etherpad.opendev.org/p/nova-2025.1-ptg#L686
17:55:20 ivveh yeah, i wouldn't know how to do it at this point, i was thinking of having a pool of cores for this use and somehow allocate to those cores via vms (no matter how many volumes they had). i also need to do the same thing for virtiofsd (a different more complex story as i also have to figure out how to force it to use fifo or change some code)
17:56:19 sean-k-mooney ivveh: so this level of low level customstion of the domain is onlyt possibe via modifying the in tree driver
17:56:41 sean-k-mooney upstream we consier any out of band modification of the dmoain to make the vm unsupported
17:56:49 ivveh yeah, thats what i thought. i was hoping to avoid it, but..
17:57:23 sean-k-mooney ivveh: we only added the iniall use of virtiofs this cycle
17:57:43 sean-k-mooney so we have not looekd at any kind of affinity for vritio fs deamon
17:57:44 ivveh my usecase is very specific as i know how many and how large my vms can be and i wanna assign them a certain amount of cores
17:58:16 sean-k-mooney i see. that not really a usecase that is very compatible with cloud computeing :)
17:58:37 ivveh depends on what flavors you rent ;)
17:58:50 ivveh but i get your point
17:59:18 sean-k-mooney waht i mean is we allow you to express constratis like "i want this vm to have dedicated pinned cpus" and obviosly you can create falvors with X amount of cpus
17:59:32 sean-k-mooney but we intentioally do not allow you to do direct maping of logcial cpus to host cpus
17:59:46 ivveh yeah no, i understand openstack needs to have its constraints, its normal and acceptable
17:59:49 sean-k-mooney nova can do that internlly but its not exposed directly in the flavor
18:00:18 ivveh for shenenings you have to go custom
18:00:41 sean-k-mooney we talked about having a pool for iothread. but we didnt want to have to schdule on them
18:01:32 ivveh i think either way, it would be great for nova to have a iothread pool that nova/cinder could take resources from (as these days defaults aren't enough)
18:03:00 ivveh would be great to have like flavors with iothread spec extraspec for example, to be able to utilize those resources, or not
18:03:21 sean-k-mooney when we dicussed it the idea was for it to just be an addtion set of core, taht woould default to cpu_shared_set if not defiend in the config
18:04:38 sean-k-mooney i.e. add a iothread_set to nova. those cpu could overlap with cpu_shared_set but now cpu_dedicated_set. we kind of felt that was too complex to start with
18:04:44 sean-k-mooney that does not mean we could not add that later
18:06:12 ivveh yea if you use cpu_shared_set and vms are pinned then they would always be free for stuff like iothreads or virtiofsd
18:06:54 sean-k-mooney so we already supprot moving the emulator thread to cpu_shared_set for pinned vms
18:07:11 sean-k-mooney so we were effectivly going to treat the extra iothread the same
18:07:49 ivveh or cpu_isolation if you wanna let things do whatever, i guess
#openstack-nova - 2025-04-01
01:56:08 opendevreview Yaguang Tang proposed openstack/nova stable/2023.2: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/945903
06:52:10 opendevreview Yaguang Tang proposed openstack/nova stable/2024.1: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/945816
09:28:55 sahid o/
09:29:26 sahid any chance to have review regarding that one, et the serie behind?
09:29:27 sahid https://review.opendev.org/c/openstack/neutron/+/940983/6
09:29:35 sahid it's waiting for a while now :-)
09:31:54 sean-k-mooney i assume you ment ot put that in the neutron channel
09:32:12 stephenfin sean-k-mooney: trivial README change here if you've 3.5 seconds https://review.opendev.org/c/openstack/nova/+/944994
09:32:25 sean-k-mooney sahid: but i would not recommend creating a theread pool dynmaiclly in a plugin
09:32:46 sean-k-mooney sahid: if your going to use thread pools you shoudl create one globaly for neutron to use and reuse it
09:32:50 sean-k-mooney like we do in nova
09:34:00 sahid sean-k-mooney: oh yes... my mistake
09:34:22 sahid sean-k-mooney: that is an interesting point yes
09:34:41 sean-k-mooney sahid: https://review.opendev.org/c/openstack/nova/+/922497
09:35:03 sahid i will discuss that with neutron, i think ralonsoh may also need it from it's change to the l3 agent
09:35:09 sahid its
09:35:09 sean-k-mooney actully that not quite the patch i wanted
09:35:36 sean-k-mooney well no that uses futureist
09:36:19 sean-k-mooney oh im not adding eventlet tpool there im just moving the import
09:36:26 sean-k-mooney thats what was confusing me
09:40:00 sahid in all cases I think that make sense to have one global thread pool and each pick on it, so each service will use its own thread pool
09:41:00 sahid but well some time we may need to have one context os threads so we can play with them, join them or kill them
09:44:11 sean-k-mooney sahid: you shoudl never kill a thread in python
09:44:54 sean-k-mooney you shoudl be using futures for the most part when you need to wait on results
09:45:11 sean-k-mooney if you need to kill something you should be using a process pool
09:45:22 sean-k-mooney otherwise you need to dispatch cancelable tasks
09:46:03 sean-k-mooney killing a thread via python is generally unsafe, there is no public api to do that and you have to fall abck to posix hacks, which mean you can leak locks and filehandels
12:14:10 opendevreview sean mooney proposed openstack/osc-placement master: Add bindep.txt for ubunutu 24.04 support https://review.opendev.org/c/openstack/osc-placement/+/946031
12:14:49 opendevreview sean mooney proposed openstack/osc-placement master: Add bindep.txt for ubunutu 24.04 support https://review.opendev.org/c/openstack/osc-placement/+/946031
13:07:44 sean-k-mooney hi folks https://review.opendev.org/c/openstack/osc-placement/+/946031 seam to fix the osc-placement docs jobs. we will need to backport that to stable 2025.1 as well
13:08:38 sean-k-mooney we can do that after the release. tl;dr we need a bindep file to install pcre because the header is not transitivly installed on ubuntu 24.04
13:23:16 cardoe Hoping to get https://review.opendev.org/c/openstack/nova/+/942019 on your folks radar too. Really helps in figuring out why something failed to get the error message instead of the hex memory address of the error message.
13:25:07 gibi cardoe: I've approved the patch. Thanks for pushing a fix
13:25:49 cardoe Thank you. :)
14:08:20 gibi sean-k-mooney: bauzas: could one of you take a look at this simple os_traits addition https://review.opendev.org/c/openstack/os-traits/+/944049 for OTU?
14:09:06 sean-k-mooney sure but if we plan do do a realase for that we shoudl include https://review.opendev.org/c/openstack/os-traits/+/940418
14:09:09 bauzas done
14:12:17 gibi sean-k-mooney: sure
14:14:43 dansmith gibi: my test should have caught that I was iterating RCs for no reason.. do you mind if I put a slightly-unrealistic allocation in for the PCI device in the test where there are two RCs to make sure we only call invalidate once?
14:15:25 dansmith PCI in placement would only have one CUSTOM_PCI_X_Y:1 thing in the allocation, but if I put two I can make sure I'm only doing it once
14:16:32 gibi dansmith: I don't mind at all
14:16:41 dansmith cool
14:16:53 dansmith gibi: are you walking up the series again? if so, I'll hold off pushing this fix
14:17:08 opendevreview Rajesh Tailor proposed openstack/nova master: Add upgrade status check for duplicate cell names https://review.opendev.org/c/openstack/nova/+/901810
14:18:20 opendevreview Merged openstack/os-traits master: Add HW_PCI_ONE_TIME_USE trait https://review.opendev.org/c/openstack/os-traits/+/944049
14:27:05 gibi dansmith: yeah I'm reviewing at the moment
14:27:14 dansmith ack, i'll hold off
14:27:59 gibi thanks
14:40:31 artom Uggla, heads up, new security/nova x-project topic for PTL at https://etherpad.opendev.org/p/nova-2025.2-ptg#L77
14:54:26 gibi dansmith: I finished reviewing the stack
14:54:46 dansmith gibi: cool, thanks, I'm just running tests after removing the spec copy
14:54:56 gibi OK
14:57:56 opendevreview Rajesh Tailor proposed openstack/nova master: Update the api-ref for unshelve https://review.opendev.org/c/openstack/nova/+/938054
14:58:13 gibi dansmith: do you plan to push some functional test coverage top of the series?
14:59:47 dansmith I haven't gone deeply into the functional tests for pci yet, because I've been sort of working with my devstack (and scheming about getting it tested in a job)
15:00:21 dansmith if you have a pointer to a good place to look at something that would be applicable for inspiration, I can do that
15:00:58 gibi sure: https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/test_pci_in_placement.py this has good examples
15:01:48 gibi actually VM boots with PCI in Placement starts here https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/test_pci_in_placement.py#L1618
15:02:24 dansmith cool, I'll get to a stopping point in the other thing I'm doing soon and try to add some more of that
15:02:41 bauzas oh doh

Earlier   Later