Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-07-10
17:54:55 melwitt sean-k-mooney: I think this cycle. unless I'm massively missing something about it 😛
17:55:29 sean-k-mooney thats more a question of do you think we cna do that and your other feature but if you think we can review both im not agiasnt doign that now
17:55:44 sean-k-mooney i would love to see us make unifed limits the default in 2025.1
17:55:52 sean-k-mooney so making incremental progress to that is good
17:55:53 melwitt the WIP code is all it should take but perhaps people will find other issues about it
17:56:25 sean-k-mooney oh cool i have not looked at that btu the fact it exists is promising
17:57:03 sean-k-mooney yoru not refering to the oslo.limits poc right, you have a nova poc for this
17:57:14 sean-k-mooney ah https://review.opendev.org/c/openstack/nova/+/923813
17:57:58 melwitt it should be only two patches, one for nova-manage limits migrate_to_unified_limits (to make it give more information like advice on what limits need to be created after running it) and one patch to check the config option and consider none/zero limit as unlimited if configured
17:58:08 sean-k-mooney hum that is not quite what i was expecting but it proably would work
17:59:14 sean-k-mooney i have not read the spec yet but i was expecting somethign like, ask keystone for all limit it supprot then check only those limits
17:59:31 melwitt ok, if you can add a comment on the spec or patch I can potentially change it. I proposed what first came to my mind
17:59:46 sean-k-mooney insead of "oh i got zero ignore if config option is set"
18:00:00 melwitt ah ok. that might work too, have to try it
18:00:28 sean-k-mooney so i guess there is only one edge case that matters
18:00:50 sean-k-mooney what happens in these two cases
18:01:01 sean-k-mooney i recuest a resouce and no limit is defied
18:01:10 sean-k-mooney i request a resouce and its defied as 0
18:04:10 sean-k-mooney with your code i think those will be treated the same
18:04:23 sean-k-mooney but im not sure if they should be
18:06:09 sean-k-mooney imo i think no limit defiend shoudl be unlimeted and limit defied as 0 mean you can not use it.
18:06:20 sean-k-mooney but i know others had different views
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.

Earlier   Later