Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-17
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
08:27:25 bauzas Uggla: I forgot that you're now the PTL in projects.yaml so I can't longer automatically have a PTL-Approved label in Gerrit, can you please +1 again https://review.opendev.org/c/openstack/releases/+/943801 ?
08:28:17 Uggla Hello bauzas, done
08:28:20 bauzas ty
08:28:44 bauzas I'll start to modify the paperwork documentation for the new PTL :)
08:29:15 Uggla cool
08:29:27 bauzas once https://review.opendev.org/c/openstack/releases/+/943941, you'll be the new PTL :)
08:31:34 bauzas Uggla: could you please +1 https://review.opendev.org/c/openstack/releases/+/943947 ?
08:32:32 Uggla done as well
08:44:32 bauzas fun, can't log into the openstack wiki
08:44:35 bauzas anyone else ?
08:47:35 Uggla bauzas, same for me apparently
08:47:52 bauzas I left a ping in #openstack-infra
08:48:02 Uggla bauzas, nop it is slow but ok
08:48:26 bauzas we should move the wiki pages to the nova internal docs eventually, and just leave the meeting agenda as an etherpad
08:48:50 bauzas no need for us to continue to run a wiki
08:49:08 gibi for me it is not slow but actually not log in just put me back to where I started the login process
08:49:14 bauzas and many times it's either slow or broken
08:49:23 bauzas gibi: same behaviour here
08:50:03 bauzas I'm no longer a PTL but I have time :)
08:51:31 Uggla login is working but it is very sloooow.
09:25:48 opendevreview OpenStack Release Bot proposed openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840
09:25:51 opendevreview OpenStack Release Bot proposed openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841
09:25:53 opendevreview OpenStack Release Bot proposed openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842
10:06:16 opendevreview Merged openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713
12:43:46 opendevreview Merged openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871
12:44:39 frickler \o/
12:48:04 opendevreview Merged openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840
12:59:41 opendevreview Merged openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841
12:59:43 opendevreview Merged openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842
13:57:28 gibi bauzas: FYI this is the PCI in Placement fix we discussed before in our planning. https://review.opendev.org/q/topic:%22bug/2098496%22 Dan is already +2. I know that we are in the RC quite period so I'm just asking for review, but I'm OK to keep this open until the final release and then land it on master and backport to stable 2025.1
13:57:36 gibi no need for an RC2 just for this
14:04:37 dansmith bauzas: it's pretty nasty since it consumes more PCI devices than the user asked for, so we definitely need to backport that if no rc2
14:05:07 dansmith usually the justification for an rc2 is that it fixes a regression that would be in this release.. gibi when did this bug get introduced do you know?

Earlier   Later