Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-07-10
18:08:13 sean-k-mooney melwitt: ill refect on your spec but not tonight, probaly friday
18:08:55 sean-k-mooney but thats what my intition expects i just dont recall all the context
18:09:44 sean-k-mooney if we take the approch im suggesting im not even sure it requries a cofnig option beyond the quota driver
18:10:25 sean-k-mooney since registering the limits with 0 or any value starts enforcing that limit
18:11:22 sean-k-mooney although i could see use wanting this to be explict too in case anywone is currently using the unifed limits driver in production
18:32:52 opendevreview sean mooney proposed openstack/nova stable/2024.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923878
18:51:47 melwitt sean-k-mooney: sorry, was on a call. yeah, I hear you. where I'm coming from ultimately is I'm concerned about the fallout potentially of when we switch the default to unified limits. I keep envisioning the scenario where as soon as they install or upgrade, all server creates start failing because they forgot or missed setting one limit
18:52:32 melwitt so at the core of it I want to prevent operator pain and I'm sure there's other ways to handle it that I haven't thought of
18:55:39 sean-k-mooney yep i want systems to more or less "just work" when we switch but i dont think we shoudl force peole to define limtis for things that previously coudl not have a limit
18:56:14 sean-k-mooney so that why im usggeting treating no registered limit as unlimited and registered with 0 as not allowed
18:56:26 sean-k-mooney or over quota when you try ot request one of that thing
18:57:09 sean-k-mooney the problem of couse if if we do that when we change the default everythign becomes unlimited
18:57:19 sean-k-mooney unless you run the migration tool
18:57:26 melwitt sean-k-mooney: ok, yeah that makes sense
18:57:39 melwitt yeah :/
18:57:42 sean-k-mooney i think thats where the idea was if any limti is regesterd
18:57:50 sean-k-mooney then we know they have started configuring it
18:57:51 melwitt ah, right
18:58:14 sean-k-mooney so there are 3 cases. no limits at all -> they didnt migrate
18:58:34 sean-k-mooney there are some registered limits -> only those resocue classes are enforced
18:58:52 sean-k-mooney all resources classes in the request have limits -> all are enforced
18:59:14 melwitt that makes sense
19:03:03 sean-k-mooney your patch treats no limit and limit of 0 as the same. so that is simpler then i was suggesting above
19:03:21 sean-k-mooney im not sure if that is enough or if we need the extra complexity of above
19:16:46 melwitt sean-k-mooney: it's likely oversimplified ... I thought of it because oslo.limit literally returns 0 for no limit, and doing something smarter will need additional keystone API calls. but not being able to differentiate between intentionally 0 and not is probably too restricting
19:33:01 sean-k-mooney i think an extra call while not ideall is ok
19:33:17 sean-k-mooney espciclaly if its opt in vai a cofnig option and you can turn it off once your fully upgraded
19:33:30 sean-k-mooney its like the placement fallback query
19:33:44 sean-k-mooney for pcpus as vcpus
19:35:14 melwitt yeah. although making it opt in means the default behavior will be the "if you missed anything everything fails until you fix it"
19:36:43 sean-k-mooney i was thinking opt out for this release and deprecate it next release then drop it in 2025.2
19:37:27 sean-k-mooney so thise release old quota driver by default and opt out if you use unified limit
19:37:53 sean-k-mooney next release default to unifed limits and deprecat the extra option in the slurp
19:38:17 sean-k-mooney 2025.2 or later drop the config and extra query
19:38:35 sean-k-mooney that makes 2025.1 the cross over release where most will upgrade to unified limtis
19:38:48 sean-k-mooney im not sure if that is too fast or not
19:40:06 melwitt hm, yeah. not sure
20:29:19 sean-k-mooney do you think it would take much to poc the limt checking approch like you did with the 0 as unlimited patch
20:29:42 sean-k-mooney i.e. with the extra api call so we can compare and contrast
20:30:10 sean-k-mooney im not saying no to what you propsoed but im wondering how easy it is to do one vs the other
20:36:51 melwitt sean-k-mooney: sure I can do that. not a problem at all
22:39:26 opendevreview sean mooney proposed openstack/nova stable/2024.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923878
22:40:20 opendevreview sean mooney proposed openstack/nova stable/2023.2: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923907
22:40:48 opendevreview sean mooney proposed openstack/nova stable/2023.2: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923907
22:41:59 opendevreview sean mooney proposed openstack/nova stable/2023.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923908
23:03:08 opendevreview Jay Faulkner proposed openstack/nova master: [ironic] Factor out metadata and send to ironic https://review.opendev.org/c/openstack/nova/+/923910
23:03:44 JayF sean-k-mooney: ^ the new unified patch, it's passing unit tests locally but I haven't reviewed it from a gerrit-perspective yet as it's my EOD (I won the race to get the tests passing :D)
23:05:38 opendevreview Jay Faulkner proposed openstack/nova master: [ironic] Factor out metadata and send to ironic https://review.opendev.org/c/openstack/nova/+/923910
#openstack-nova - 2024-07-11
00:11:32 opendevreview keerthivasan proposed openstack/nova master: Move nova-manage db purge to nova-audit https://review.opendev.org/c/openstack/nova/+/708783
05:32:16 opendevreview Balazs Gibizer proposed openstack/nova master: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923924
06:56:09 opendevreview Balazs Gibizer proposed openstack/nova master: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923924
07:27:43 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923878
08:06:11 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Reject cpu_model_extra_flags when cpu_mode='none' https://review.opendev.org/c/openstack/nova/+/923933
09:09:03 gibi stephenfin: we are sort on cores this week. Could you check a small unit test stabilization patch https://review.opendev.org/c/openstack/nova/+/923924 ?
09:13:12 songwenping__ gibi, sean-k-mooney: hi, does evacute has rescheduler process?
09:13:24 sean-k-mooney songwenping__: no
09:13:42 sean-k-mooney if evacuate fails you should just evacuate again
09:14:10 sean-k-mooney we do not reschule any move operation as far as im aware
09:14:19 songwenping__ i find build,unshelve and migrate have rescheduler, right?
09:14:58 sean-k-mooney live migrate defintly does not i dont thik coldmigrate/resize does either
09:15:07 sean-k-mooney build does but im not sure about unshelve
09:15:28 sean-k-mooney well that not entirly true
09:15:47 sean-k-mooney we got rid of reschdule entirly and replaced it with alternate_host 5 or 6 years ago
09:15:50 sean-k-mooney maybe more
09:16:23 sean-k-mooney i think if pre_live migtrate failes we may check the alternate hosts and the same mighgt be true of other move op
09:16:41 sean-k-mooney but we never retry and reschdule once we attemet to start the migration of data
09:16:48 songwenping__ build still entired reschedule?
09:16:56 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.1: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923935
09:17:31 sean-k-mooney no its not a rescule because we dont go back to the scheduler it uses the alternitve hosts the scheduler orgially provided
09:17:43 sean-k-mooney by default the schduler gives us 3 hosts
09:17:55 sean-k-mooney the condocutor tries those in order
09:18:23 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.2: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923936
09:18:26 sean-k-mooney provided the allocation candiate can still be claimed in placement
09:18:41 songwenping__ got it.
09:18:51 sean-k-mooney if we fail early enouch in evacuate/resize we may do the same
09:20:16 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.1: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923937
09:22:19 sean-k-mooney songwenping__: https://docs.openstack.org/nova/latest/contributor/resize-and-cold-migrate.html#resource-claims
09:22:21 songwenping__ as nova-scheduler workers has same host_state info, if two evacuations come at the same time, the resource is enough in nova-scheduler, but nova-compute claim failed as two vms required resources exceed the remain resources on nova-compute.
09:22:53 sean-k-mooney songwenping__: that wont happen in general
09:23:12 sean-k-mooney it will only happen if the vm is using a resouce not tracked in placment or with numa toplogy
09:23:51 sean-k-mooney so before we call teh compute we the conductor creates an atomic claim in placement
09:24:02 sean-k-mooney for cpu/ram/disk and some other resouces
09:24:15 songwenping__ yeah, but in our HA mechanism, it occurs.
09:24:59 sean-k-mooney the vm should never get to the comptue part, are you runnign placement on an Active Active galera by any chance
09:25:36 sean-k-mooney active/active meaning multi master/multi writer setup
09:31:20 songwenping__ maybe our nova-scheduler use host_state cache info, not get ar from placement.
09:31:59 sean-k-mooney thats not how that works
09:32:12 sean-k-mooney unless this is pre rocky
09:32:56 songwenping__ yeah, we use rocky :)
09:35:03 songwenping__ the cache mechanism is deprecated after rocky?
09:35:49 sean-k-mooney there is a cache but we first filter in placement before the schduler filtere run and then claim atotmicaly after to avoid races
09:38:01 songwenping__ sean-k-mooney: got it, thanks.
10:47:10 frickler elodilles: you offered help some days ago, additional reviews for https://review.opendev.org/q/topic:%22format-inspector%22+status:open would be nice I think
10:55:28 elodilles frickler: ACK, thanks for the ping. i did not say it upstream, but i'm mostly off today. so i might only get there to review the patches tomorrow ~afternoonish
11:09:26 frickler elodilles: ah, ok, thx for the update, let's hope things might be resolved until then
12:14:26 elodilles frickler: i've reviewed and +2+W'd the stable/2024.1 patches (except the last patch as that is not merged on master yet)
13:07:08 sean-k-mooney the last 2 patches that sables the unit test we belive are just ened for old veriosn of the tools
13:07:41 sean-k-mooney frickler: elodilles basically we were backportign those downstream too train/wallaby and had ci failures
13:09:54 opendevreview Arnaud Morin proposed openstack/nova master: Avoid failing if compute_id file is empty https://review.opendev.org/c/openstack/nova/+/923953
13:19:18 frickler sean-k-mooney: yes, I'm not too worried about those, but we are running with the major iso format-inspector patch downstream now, so it would be comforting to see it merged

Earlier   Later