| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-10 | |||
| 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 | |
| 13:58:09 | mnaser | so potentially a single lookup if there is one other node for example | |
| 13:59:29 | mnaser | and I think I can't really do a cache inside of the filter for a spec because its invoked for each host | |
| 14:00:55 | sean-k-mooney | the filter runs per host however | |
| 14:01:27 | sean-k-mooney | so you multiple that by the number of host reteruend from placment * the number of vm in the build request | |
| 14:01:51 | opendevreview | Merged openstack/nova stable/2024.1: port format inspector tests from glance https://review.opendev.org/c/openstack/nova/+/923722 | |
| 14:02:44 | opendevreview | Merged openstack/nova stable/2024.1: Reproduce iso regression with deep format inspection https://review.opendev.org/c/openstack/nova/+/923723 | |
| 14:03:01 | sean-k-mooney | mnaser: what i was thinkign is if we were to do this we would have the hostmanager get ll the host in the group and the aggreates for thos groups once before running the filter on each host and storing the info in either the hoststate object or request sepc so we can share that info acrros each vm and across each host | |