Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-12
09:06:22 Uggla bauzas, did you had a chance to look at https://review.opendev.org/c/openstack/nova-specs/+/831506/4/specs/zed/approved/unshelve-to-host.rst just to know if it looks ok for you ?
09:12:28 bauzas Uggla: not yet, will do today
09:15:36 Uggla bauzas, no hurries so far.
10:03:57 bauzas gibi: sean-k-mooney: do you remember if we verify the usage about an inventory if we create a new allocation directly by calling the Placement API ?
10:04:11 bauzas or do we verify it by Nova ?
10:05:07 sean-k-mooney you mean prevent over allocation
10:05:27 sean-k-mooney we prevent over allocation in placment i belive
10:06:37 sean-k-mooney so if two boot requests both recive an allocation_candiate for the same host in parallel and then both try to allocate that candiate only one will succeed and that is enforce by placment if im not mistaken
10:07:28 sean-k-mooney gibi: ^ that is correct right? or have i been fundementaly misunderstanding placment for years
10:07:45 bauzas sean-k-mooney: gibi: let's discuss this on downstream IRC, I have a BZ
10:08:12 sean-k-mooney ok just getting coffee
10:08:18 sean-k-mooney we can have a call if it helps
10:08:38 sean-k-mooney you can get into over allocation situations if the allocation ratio is change by the way
10:08:44 sean-k-mooney brb
10:18:51 bauzas I need to prepare lunch for my kid, but let's discuss this when I'm back
11:12:13 gibi sorry I was having lunch
11:13:19 gibi but overall yes, placement prevent overallocation via allocation creation, placement does not prevent overallocation via inventory modification (i.e changing allocation ratio, reserved, or total field)
11:14:38 sean-k-mooney right and when you go into an overallocated situation via inventory modifcaiotn placemnt allows you to free allocaitons agaisnt that inventory but wont allow you to crate new ones until you have enough capsity
11:15:33 sean-k-mooney so we have seen that were people have updated the cpu_pin_set or altered the allocation raitos and over commited it can prevent things like evacuate form working
11:16:05 sean-k-mooney since evacuate currently uses one allcoation isntead of two
11:22:59 gibi yes
11:23:01 gibi for all tree
11:23:03 gibi three
11:23:22 gibi in an overallocation situation inventory can change but allocation cannot
11:23:28 gibi except removal
11:23:35 gibi so you can delete allocations
11:25:47 gibi and yes evac is special as it needs to modify the single allocation of the VM
11:27:09 gibi hm but non evacuation also needs to move the VM allocation from the VM uuid to the migration uuid so that would fail too in an overallocation
11:27:33 gibi this is suboptimal as it prevents cleaning up an overallocated host by moving VMs out
11:28:07 gibi so I would temporary remove the overallocation by bumping allocation ratio high up, move the VMs out, and then restore the allocation ratio
11:28:51 sean-k-mooney ya that is the workaround for now
11:29:13 sean-k-mooney ideally we woudl mvoe to useing the migration object to track either the source or dest allcoations
11:29:39 sean-k-mooney im not sure bauzas case was related to evac
11:29:44 sean-k-mooney we can see when they are back
11:30:25 gibi and we would also need to special case the allocation update that only change consumer uuid, in placement to be allowed even in overallocated situation
11:39:35 gibi yepp, I checked decreasing allocation is rejected, but deleting allocation is accepted in overallocation case
12:37:27 opendevreview Pavlo Shchelokovskyy proposed openstack/nova master: Sort PCI devices by their address https://review.opendev.org/c/openstack/nova/+/830136
14:09:13 opendevreview Alexey Stupnikov proposed openstack/nova stable/wallaby: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/841483
14:15:39 opendevreview Hervé Beraud proposed openstack/nova-specs master: Fix typo https://review.opendev.org/c/openstack/nova-specs/+/841600
14:17:38 opendevreview Hervé Beraud proposed openstack/nova-specs master: Fix typo https://review.opendev.org/c/openstack/nova-specs/+/841600
16:09:44 opendevreview Merged openstack/nova-specs master: Fix typo https://review.opendev.org/c/openstack/nova-specs/+/841600
16:54:06 opendevreview Gorka Eguileor proposed openstack/nova master: Fix extending non LUKSv1 encrypted volumes https://review.opendev.org/c/openstack/nova/+/836064
16:58:11 geguileo stephenfin: I had to change the commit message, could you +2 it again, please: https://review.opendev.org/c/openstack/nova/+/836064
16:58:34 geguileo sean-k-mooney: ^
16:58:36 stephenfin done
16:58:45 geguileo stephenfin: wow, that was quick, thanks :-)
17:22:25 sean-k-mooney geguileo: ill take a look again shortly too
17:22:41 sean-k-mooney ah stephen put it back in the gate
17:22:43 sean-k-mooney cool
17:32:15 mnaser sean-k-mooney: do you think the `hw:mlock` thing deserves a full-on spec as well if we want to do that as well?
17:33:45 mnaser (i.e. https://review.opendev.org/c/openstack/nova/+/778347)
17:33:59 mnaser if so, i can try and ask ricolin to work on that as well
17:34:31 sean-k-mooney technically its a seperate feature which could be a seperate spec but im ok to combine the to unless others want it split out
17:35:14 sean-k-mooney i can unabandone that if you like if ricolin wants to take over the patch
17:36:07 sean-k-mooney my inital patch technically does not enfoce that you ahve a mem_page_size
17:36:16 sean-k-mooney so it can lead to OOM issues
17:36:23 sean-k-mooney but it was functional
17:37:04 sean-k-mooney it looks like artom and stephenfin had a prference for hw:locked_memory instead of hw:mlock
17:37:12 sean-k-mooney so it proably makes sense to at least make that change
17:37:52 sean-k-mooney i was ment ot re review the viommu spec today too sorry ricolin
17:38:21 sean-k-mooney ill try and get back to it tomorrow but likely wont get to it today
18:15:07 opendevreview Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing stuff https://review.opendev.org/c/openstack/nova/+/841626
23:29:13 ricolin sean-k-mooney: yeah, I can help with the mlock patch, and thanks for your review:)
#openstack-nova - 2022-05-13
07:04:10 opendevreview Wenping Song proposed openstack/os-traits master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-traits/+/841682
08:42:20 opendevreview Wenping Song proposed openstack/placement master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/placement/+/841690
08:42:39 opendevreview Wenping Song proposed openstack/placement master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/placement/+/841690
09:20:32 opendevreview Wenping Song proposed openstack/os-resource-classes master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-resource-classes/+/841700
09:46:43 opendevreview Wenping Song proposed openstack/os-resource-classes master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/os-resource-classes/+/841700
10:12:03 sean-k-mooney ricolin: +1 on the spec
10:12:23 sean-k-mooney ricolin: i have resotred the mlock patch too so feel free to updated it
10:12:29 ricolin thanks sean-k-mooney :)
10:15:28 sean-k-mooney ricolin: if you adress the extra spec name im baicly +2 ill read over it again when you respin but no rush
10:24:09 opendevreview Rico Lin proposed openstack/nova-specs master: Add vIOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310
10:25:12 ricolin sean-k-mooney: done ^^^ :)
10:28:37 sean-k-mooney +2 :) am milestone 1 i think is thursday. assuming gibi or others approve the spec can you submit the patch to os-traits to add the traits
10:28:55 sean-k-mooney if we merge that before tursday then the traits can be included in the m1 relases of os-traits
10:30:37 sean-k-mooney nova's unit tests need the traits to be in a release version of os-traits to pass if its not merge by then its not really a big deal we will just do another release whenever they land and the nova code look good to merge
10:51:22 stephenfin sean-k-mooney: gibi: melwitt: Reviewed that PCI in placement spec. Looks pretty good, though I'm convinced you're making an unnecessary rod for your own back in trying to port that dynamic PF/VF logic to placement land ;-)
11:00:54 sean-k-mooney stephenfin: ya it is complicating things
11:01:15 sean-k-mooney stephenfin: that use case is really only for sriov nics
11:01:23 sean-k-mooney as in for neuton ports
11:01:31 sean-k-mooney i dont think it really exists for pci alias
11:02:09 sean-k-mooney so we can kind of punt. technialy it applise to the alias too but i dont think that is a common usecase there
11:02:45 sean-k-mooney stephenfin: you might want to look over ricolin's spec for the viommu support
11:02:51 sean-k-mooney its pretty short
11:03:17 sean-k-mooney https://review.opendev.org/c/openstack/nova-specs/+/840310
11:04:00 stephenfin sure
11:06:36 gibi stephenfin: so you suggest that deciding to whitelist either the PF or its VFs are rarely used? I think the opposite. It is so easy to just whitelist everthing under 0000:81:* both PF and VF, without thingking to much, and then start using the compute for both direct and direct-physical ports, it just works, so I think there is a lot of deployment out there that might not need to whitelist both but
11:06:42 gibi they did
11:07:44 gibi if we start rejecting such config there will be a lot of pain figuring out a whitelist in these deployments that matches the current consumption
11:08:10 sean-k-mooney im not sure really. im tempted to say perhaps we sould only support that if you are not trackign devices in placment
11:08:45 sean-k-mooney and in the mvp implement supprot for only tracking deivces as PFs or VFs
11:09:03 sean-k-mooney and then we could add the mixed suport after if needed
11:09:04 stephenfin No, I'm suggesting people wanting to use both 'direct' and 'direct-physical' on a single host is likely rare. I think it's reasonable to insist that users that use wildcard device addresses (or vendor/device IDs) choose whether they want to consume the VFs or PFs
11:09:47 sean-k-mooney stephenfin: well your suggestiong they make that dissionc staticaly at deployment time
11:09:56 stephenfin At the moment, a user can dynamically choose whether they consume the PF or one or more of the VFs. I think moving to a static model makes sense now
11:09:59 stephenfin Yup
11:10:01 sean-k-mooney rather then dynmical as workloads are schulded
11:10:05 stephenfin exactly
11:10:32 sean-k-mooney i think pf passhtough is much less common then vf

Earlier   Later