Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-17
13:57:53 Uggla @dansmith, you will learn French, that's a good start !
13:58:21 dansmith I will not.. one french translation via google from me per cycle and that was the one for flamingo :)
13:59:28 dansmith the only one I really "know" is "voulez-vous coucher ... " you know the rest :)
13:59:31 Uggla @bauzas, I'll try to do it for flamingo, but I hope, you will be not far away to check it. ;)
14:00:49 bauzas Uggla: GMaps tells me a distance of 36 kms by road indeed
14:01:03 Uggla @dansmith, a useful one. ;)
14:01:58 Uggla bauzas, any chance you merge couple of FUP for vGPU before RC 1 ?
14:02:54 dansmith we're already late right? unless it's something critical I'd vote to stay the course, backport if it's important
14:05:21 bauzas Uggla: I'm a bit lost now, the bottom patches are on gate, but for the other 3 ones, there is a still -1 for the 3rd
14:05:54 bauzas Uggla: tbc, we can merge the two first as those are in the gate, but for the other ones, I don't think so unfortunately :(
14:07:45 bauzas if those two patches merge before we merge rc1, all good but I won't await them unfortunately
14:08:54 Uggla bauzas, the one for the doc is important. but it can be backported without pb.
14:09:05 bauzas yep, I know :(
14:10:09 Uggla I can put it down in the serie if it helps.
14:11:33 Uggla I have fixed the comments from @gibi and @sean-k-mooney, but it needs a review. Anyway let me know if I can help if not then we'll see and backport.
15:43:52 dansmith gibi: sorry to complicate the workflow with those grammar fixes. I was thinking I could +2 it after that and totally forgot about the TODOs, else I would have just left the comments
15:44:01 gibi no worries
15:44:26 gibi it easy to just pull the new ps from gerrit and continue from that
15:44:39 dansmith as long as no more changes were local, but yeah
15:45:04 gibi yeah I had no local changes to apply on top with a stash / stash pop
16:01:15 dansmith bauzas: fancy re-applying your +2 to this? https://review.opendev.org/c/openstack/nova-specs/+/943486
16:16:28 gibi dansmith: left some comments in the spec
16:26:58 dansmith gibi: thanks, I totally see now why those migrate scenarios sound wrong, obviously not my intention :)
16:27:13 gibi cool
16:27:28 dansmith gibi: left a question for you on the evac thing, I don't have an easy way to test that locally, but I'm also not sure what you're worried about specifically
16:28:48 gibi dansmith: I feel evac is different but I need to take a look at the code to see how it is different...
16:29:46 dansmith gibi: okay did you want me to just mention that we need to look at that in the implementation or dig into the difference? I could *try* to set up something to test the evac but I'm not sure if I'll be able to squeeze it in
16:30:18 gibi I'm OK to mention evac as also probably affected and then later we can figure out what that really means
16:32:28 dansmith okay
16:33:04 gibi https://github.com/openstack/nova/blob/6b45672b23db47ccbf74dbda4f2678fd25ea22ed/nova/conductor/manager.py#L1325 the place conductor schedules the evac, but above it we have the old case where the evac is forced to a host and skipping the scheduler
16:33:50 gibi I'm not sure if we try to move the allocation to the migration uuid in either case
16:34:07 dansmith ah, okay, but probably the same principle applies here if you're in transition and don't have the PCI-i-p filter enabled such that we heal the allocation for it and the inventory right?
16:34:35 dansmith since we key the inventory reserved=1 off of the objects.PCIDevice and not the allocation, I think we'll reserve the device immediately regardless
16:35:30 bauzas maybe I misunderstood, but I was able to understand what "burned" was meaning
16:35:58 bauzas 'burned' to me means that this is reserved and you can't longer use this device unless you're able to unreserve it
16:36:30 bauzas so, of course, when evacuating something that was already reserved, we then also reserve the target
16:36:40 bauzas both then are 'burned'
16:36:45 gibi dansmith: my point is that if evac does not call move_allocations then evac operation will not be blocked by placement like cold/live migrate and resize that fails at move_allocations if reserved=1
16:37:28 dansmith bauzas: I think the problem is I referred to "burned" in the early part as happening immediately, but I wrote the migration lifecycle stuff using burned to mean after the allocation was dropped.. it doesn't change what we're doing, it's just not cear
16:37:47 dansmith bauzas: I think we should say "burned happens as soon as reserved is incremented", thus instances run with a "burned" device the whole time.. that will be clearer
16:37:56 bauzas cool cool
16:38:11 bauzas fwiw, nothing changes to me, this is just a documentation question, hence why I +2d it
16:38:31 bauzas we can change the spec in a follow-up if that's really that
16:38:42 dansmith gibi: ah okay
16:38:53 dansmith bauzas: yep, I'm rephrasing now
16:38:54 gibi dansmith: maybe evac will just work out of the box
16:39:21 gibi dansmith: anyhow I can try evac at some point later this week with your WIP code
16:39:47 gibi so for the spec that mention that evac might or might not be effected by the placement bug and we can refine that later
16:39:55 dansmith gibi: ack will do
16:43:42 gibi thanks
16:45:05 dansmith gibi: if the situation you described doesn't heal the allocations before we start the instance, then evacuation would be able to oversubscribe a host today, even without this I think right?
16:47:16 gibi I think the situation (i.e. not having move_allocation called) during evac, does not change the healing logic running on the destination compute. Hopefully it handles the fact that the instance uuid is allocating from two RP trees, one from the source node and one from the destination node
16:47:49 gibi but that problem preexists not otu specific
16:48:00 gibi * problem, if any
16:48:07 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
16:48:40 dansmith gibi: since we call _update() synchronously in instance_claim() I think we *have* to be fixing the allocation before we start running the instance, and would fail if we couldn't
16:49:13 dansmith anyway, see if these ^ wording updates make it clearer
16:50:21 gibi dansmith: I think we are on the same page. The healing happnes regardless of move_alloction called or not in the conductor
16:50:44 dansmith ...and synchronously such that if it fails we fail, but definitely good to confirm
16:51:12 gibi yeah
16:51:19 gibi looking at the spec...
16:51:50 dansmith also, please clarify your "over-subscribed" comment.. perhaps it's just a meaning-of-the-phrase thing
17:10:57 gibi dansmith: ack, clarified in the reivew
17:11:00 gibi *review
17:15:28 dansmith replied.. I guess it's just what you think "over-subscribed" means...
17:21:17 gibi dansmith: do we want to fix both oversubscribed case in placement?
17:21:29 gibi or just the reserved=used case?
17:21:50 dansmith gibi: I'm not sure what you mean.. does placement define over-subscribed to mean something specific?
17:22:36 gibi dansmith: I just don't want to suggest we will fix both over-subscribed case in a later bugfix. I think we only want to fix the reserved=used case
17:23:05 dansmith it'll be the same fix I think
17:23:50 dansmith I haven't actually done it yet (because I haven't decided about the signaling) but it's basically in the same place where it just adds them all up and decides if it's over.. it would actually be worse to (try to) fix it for one and not the other I think
17:24:13 dansmith I thought we were arguing over the meaning of "over-subscribed" and whether total=1,used=1,reserved=1 was "over-subscribed"? :)
17:25:53 gibi I think both is oversubscribed but they are different situations. I tink the reserved=used case is more of an allowed over subscription as nova managed VMs are not using more resources that available. The used > total case is different as it means nova VMs are using more than they should
17:26:14 dansmith yes, very much agree.. I thought that was the nit you were picking
17:26:24 dansmith or rather,
17:26:33 dansmith that you were suggesting something other than the above definition
17:27:07 gibi so I don't want to signal in this spec that we will allow used > total during move operation in the future as I'm nost sure we should allow nova-compute to even start with such config in the first pl.ace
17:28:17 dansmith okay I'm super confused
17:28:20 dansmith gmeet? :)
17:28:36 dansmith or tomorrow, if it's late for you
17:29:04 gibi we can have a quick gmeet I started my day late so I'm planned to be around longer
17:29:28 dansmith meet.google.com/njh-oqjw-azk
18:02:39 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
18:45:10 opendevreview Doug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors https://review.opendev.org/c/openstack/nova/+/942019
19:18:26 mikal Morning
19:42:04 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/941673
19:42:05 opendevreview Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277
19:45:01 opendevreview Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277
22:04:20 opendevreview Doug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors https://review.opendev.org/c/openstack/nova/+/942019
#openstack-nova - 2025-03-18
08:12:14 bauzas gibi: could you give a swing for the prelude ? https://review.opendev.org/c/openstack/nova/+/944713
08:12:58 gibi bauzas: sure
08:13:05 bauzas ta
08:16:22 gibi bauzas: could you quickly respin it to change vif mode to vif model?
08:16:35 gibi I can proxy dansmith's +2 and land it afterwards
08:17:21 bauzas gibi: sure
08:17:46 bauzas we still are awaiting the QEMU version bump to land before we tag RC1
08:18:00 bauzas hopefully today we can branch :)
08:19:11 opendevreview Sylvain Bauza proposed openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713
08:22:55 gibi bauzas: thanks, approved the prelude
08:25:11 bauzas ty

Earlier   Later