| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-10 | |||
| 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 | |
| 13:33:37 | sean-k-mooney | frickler: oh good to know. have you foudn any issue with it i should be aware of? | |
| 13:33:55 | sean-k-mooney | if you do just ping and ill take a look | |
| 13:36:55 | frickler | sean-k-mooney: sure, but no issues found so far | |
| 13:38:09 | mnaser | sean-k-mooney: btw https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/M3BBTNE22VMMZSFMGFWMJJDYEPW7VNHL/ of interest based on our discussion the other day :) | |
| 13:38:49 | mnaser | when you have a second id appreciate feeedback | |
| 13:41:47 | sean-k-mooney | you realise that is O(hosts*aggreates^2) right | |
| 13:42:47 | sean-k-mooney | im not saying that wont work | |
| 13:43:11 | sean-k-mooney | but we might need to be a littel smarter if we were to do that in nova proper in terms of performce | |
| 13:44:47 | sean-k-mooney | like see that there is a server group in teh request spec, grap all the relevent host for that server group and lookup the aggerst once in a map and pass in the relevent agrrate i the host state object ot each filter | |
| 13:45:34 | sean-k-mooney | im not sure if that will work but lookign up every aggrete reated to every other host that has an instance in the same server group per host is expensive... | |
| 13:57:52 | mnaser | sean-k-mooney: I realize it is expensive, but i couldn't think of a better approach, but also I am looking up aggregate for server groups only, so it is limiting it to the scope of hosts that are part of that host aggregate | |