Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-05
12:51:43 masahito tkajinam: thanks for the info. The gerrit board view was quite changed, so I didn't notice the conflict :) v2.100 changed same place but I can't find the "conflict" label so I was wondering why it is.
12:52:40 tkajinam masahito, I believe you could see it in the top-left (where "Active" is now shown") but the view might be a bit different according to browsers you are using
12:53:08 tkajinam see https://review.opendev.org/c/openstack/requirements/+/941939 for example
12:53:31 tkajinam and yeah the view has been changed
13:42:33 opendevreview Merged openstack/nova-specs master: Amend the specification about the data in LiveMigrate object https://review.opendev.org/c/openstack/nova-specs/+/941417
18:30:03 opendevreview Ghanshyam proposed openstack/nova master: Testing doc job on Ubuntu Noble https://review.opendev.org/c/openstack/nova/+/935577
19:41:48 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
20:00:11 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
20:28:20 opendevreview Alan Bishop proposed openstack/nova master: Show swap_progress in attachment details https://review.opendev.org/c/openstack/nova/+/941476
22:16:52 Callum027 sean-k-mooney: Regarding your suggestion to add the image name in https://review.opendev.org/c/openstack/nova/+/942766 , I don't think image_name is actually stored in system_metadata currently. At least, in our tested on our Nova deployments it doesn't actually appear to be there.
22:18:48 sean-k-mooney ya i think your right, dont try and do heroics to store it
22:19:31 sean-k-mooney Callum027: if its not aviable easily not then the uuid is fine.
22:20:00 Callum027 Yeah, we don't need it for our use case either so I'm happy with UUID only as well
22:31:52 sean-k-mooney the name doesnet actuly matter in most case that was more a syetry thing in that we do have the falvor name
23:02:07 Callum027 Come to think of it, the image name can change at any time so it's not necessarily a good idea for Nova's system metadata or the libvirt metadata to store that anyway
23:03:15 sean-k-mooney it shoudl not change after its created although glance might allow it too
23:04:57 sean-k-mooney ... not only do they allow it it is in the example https://docs.openstack.org/api-ref/image/v2/#id16
23:05:11 sean-k-mooney ew but ok uuid it is
23:43:21 opendevreview melanie witt proposed openstack/nova master: Let oslo.limit handle retrieval of the endpoint ID https://review.opendev.org/c/openstack/nova/+/943507
#openstack-nova - 2025-03-06
00:23:29 opendevreview Callum Dickinson proposed openstack/nova master: Add image meta to libvirt XML metadata https://review.opendev.org/c/openstack/nova/+/942766
02:54:06 opendevreview melanie witt proposed openstack/nova master: Let oslo.limit handle retrieval of the endpoint ID https://review.opendev.org/c/openstack/nova/+/943507
07:33:42 opendevreview Michael Still proposed openstack/nova master: Don't calculate the minimum compute version repeatedly. https://review.opendev.org/c/openstack/nova/+/940848
07:33:42 opendevreview Michael Still proposed openstack/nova master: libvirt: Add extra spec for sound device. https://review.opendev.org/c/openstack/nova/+/926126
07:33:43 opendevreview Michael Still proposed openstack/nova master: Protect older compute managers from sound model requests. https://review.opendev.org/c/openstack/nova/+/940770
07:33:43 opendevreview Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927354
08:42:41 opendevreview Xiang Wang proposed openstack/nova master: Improve Error Handling for Placement API Responses in Nova https://review.opendev.org/c/openstack/nova/+/943530
08:43:40 opendevreview Xiang Wang proposed openstack/nova master: Improve Error Handling for Placement API Responses in Nova https://review.opendev.org/c/openstack/nova/+/943530
09:57:50 opendevreview Gaudenz Steinlin proposed openstack/nova master: Make SSH compression for remote copy configurable https://review.opendev.org/c/openstack/nova/+/943377
10:49:39 sean-k-mooney gibi: bauzas this is a nice performance fix form mikal that came up during the spice series https://review.opendev.org/c/openstack/nova/+/940848 it would be nice to include that in epoxy
10:53:22 bauzas done
10:54:07 sean-k-mooney cool let me know if we have anything pendign that need another pair of eyes
10:55:03 bauzas we'll need to merge the usual release patches
10:55:09 bauzas but I'll ping folks for sure
10:56:14 sean-k-mooney im starting to prepare the same for wathcer. i diid they cycle highlights yesterday and have a draft of the prelude but i need to update launchpad blueprints and the specs repo ectra
10:56:50 sean-k-mooney i also need to confirm if watcher needs the same rpc aliases ectra that we need for nova
12:54:30 opendevreview Merged openstack/nova master: Don't calculate the minimum compute version repeatedly. https://review.opendev.org/c/openstack/nova/+/940848
13:45:22 opendevreview Gaudenz Steinlin proposed openstack/nova master: Make SSH compression for remote copy configurable https://review.opendev.org/c/openstack/nova/+/943377
15:15:19 dansmith gibi: this is a little different than I remember it originally: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L2059
15:15:35 dansmith that seems to do an atomic swap and not an allocate..delete
15:16:01 dansmith I can go dig, but you might know quicker: will that check reserved or let us get away with the swap if we're reserved?
15:24:01 gibi dansmith: I have not context but at least that seems to be a singel request from nova to placement. I don't know how placement processes that. I know that when nova tries to move an allocation that is for a reserved resource the placement call will fail.
15:24:09 dansmith okay yeah i think it will
15:24:30 gibi but I don't know the exact behavior of placement here
15:24:40 gibi I mean the internal behavior
15:25:00 dansmith what I think placement does is start a transaction, delete the source allocations, create the replacement allocations, then _check_capacity_exceeded() and if that fails, roll back the transaction
15:25:04 sean-k-mooney https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/allocations-bug-1779717.yaml
15:25:26 sean-k-mooney we can update/create mutliple allocation at once
15:25:43 dansmith right, but they will still check the reserved amount
15:25:59 sean-k-mooney possibly
15:26:05 dansmith they do
15:26:15 sean-k-mooney ok
15:26:15 dansmith https://github.com/openstack/placement/blob/master/placement/objects/allocation.py#L73
15:26:41 dansmith see my logic above, this ^ will run after the swap and fail because we're over capacity due to the reserved amount
15:26:58 sean-k-mooney right i think that what happend for evacuate too
15:27:35 dansmith yeah, so I think from the outside, it's reasonable for an api consumer to assume that "allocations.replace_all()" is just a swap but it's not
15:28:11 sean-k-mooney well maybe
15:28:29 sean-k-mooney its was not orgianlly for swappign it was for doign muitple updates i think
15:28:32 gibi from API semantic perspective it is not well defined what it means when such a POST call has multiple consumers
15:28:41 dansmith it's also reasonable to assume that we check the capacity again, I'm just saying I think it's a bit ambiguous
15:28:47 dansmith gibi: exactly
15:29:12 gibi it might be a move it might be two independent allocation in the POST
15:29:23 sean-k-mooney yep
15:29:28 dansmith so one way to resolve that would be to say "if we were over capacity before, we allow you to be over capacity by the same exact amount after, otherwise fail"
15:29:42 sean-k-mooney that or a flag to contole the behavior
15:29:50 sean-k-mooney either way i think it need a new microversion
15:30:07 dansmith yeah I was also thinking a flag would be a thing
15:30:25 dansmith sean-k-mooney: can you dig up a reference on the evacuate bug?
15:31:09 sean-k-mooney gibi found it not long ago i can check my email/irc/slack logs and see
15:31:45 sean-k-mooney i know the last time it came up as a downstream it was because the oeprator had adjusted the allcoation ratio
15:31:57 sean-k-mooney putting the host into an oversubsiped state and then later could not evacuate
15:32:10 sean-k-mooney but there was a second edge case too
15:32:56 dansmith right, so that's what I was going to say,
15:33:13 dansmith I think that an alloc ratio change or reserved change will make our existing code fail to swap an allocation of equal size, when it really shouldn't
15:33:18 dansmith for all the move ops
15:34:37 sean-k-mooney in the evacuate case i think we only have one allcoation however it just happens ot have resouce form 2 hosts or somethign slightly odd
15:35:15 dansmith any feeling on allowing the reserved check to be skipped if the total size of the allocations against a provider are not changing? or do you think we need a flag to ask for that specifically
15:35:28 dansmith I tend to think a new microversion after which we say that's the behavior is okay,
15:35:31 sean-k-mooney https://bugs.launchpad.net/nova/+bug/1943191 https://bugs.launchpad.net/nova/+bug/1924123 and https://bugs.launchpad.net/nova/+bug/1941892
15:35:37 dansmith but if we want to only do that if we specifically ask for it then...
15:36:40 dansmith heh the subject of that first bug is exactly what I'm saying yeah
15:37:39 sean-k-mooney non of those actully say evacuate bu ti think its a releated issue
15:38:02 dansmith but blocking cold migrate is worse
15:38:26 dansmith brb
15:38:34 sean-k-mooney as is sid i think, i could be wrong about this, that for evacuate we do not have a migration uuid becuase its actully not a "move op" in that sence it just rebuidl to a new host
15:38:57 sean-k-mooney so for evacuate i think we extend the single allcoaiton with rp for the dest
15:39:18 sean-k-mooney i could be wrong about that because i know we change that at some point
15:39:26 sean-k-mooney i would have to look at the detail
15:40:49 dansmith yeah idk, I'm more familiar with the cold migrate case, which is clearly broken already
15:41:05 gibi sean-k-mooney: yeah evac is implement the way you describe
15:42:33 sean-k-mooney we talked about chaging htat at some point but there was a reaons why it was hard
15:42:37 gibi I'm wondering if it is enough to check if the allocated value does not change to use the swap mode instead of using the current independent allocation mode. I mean from placement API perspective there just not enough information about the intention of the user.
15:42:55 gibi what if at some point we want a swap behavior that also decreases the size
15:43:12 dansmith gibi: I don't think there are multiple different operations are there?
15:43:17 dansmith we're using POST /allocations for both
15:43:40 dansmith and placement is using the same logic regardless of if we're deleting and re-allocating the same provider vs. different ones, AFAIK
15:44:22 gibi yeah, my point is that POST call can be understood both ways (swap or create/delete) even if the total allocated resources does not change in the process
15:44:23 dansmith but yeah that was my point.. if the operation is not further over-subscribing the provider (or maybe not changing the amount at all) it seems reasonable to let it through
15:44:26 gibi so placemetn does not know
15:44:28 dansmith yeah
15:44:36 sean-k-mooney if the set of RPs in the set of allction dont change and the total resouces consuemd dont hcange then we might be able to skip the capastiy check

Earlier   Later