| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-07-11 | |||
| 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 | |
| 14:03:51 | sean-k-mooney | mnaser: we do somethign simialr for groups already in terms of maintianign a mapping of instance uuids to hosts | |
| 14:05:08 | mnaser | yeah we have host_state.instances which anti affinity can easily use | |
| 14:05:23 | sean-k-mooney | yep thats why its there | |
| 14:05:34 | sean-k-mooney | its only optionally populated based on a config option | |
| 14:05:48 | sean-k-mooney | as it uses potentally a lost of memory | |
| 14:06:05 | sean-k-mooney | we also have a list of aggreats in the host_state too | |
| 14:06:22 | mnaser | I think I end up using that | |
| 14:06:51 | mnaser | but then I have to check what is the failure domain set to _this_ host aggregate, and lookup what it is for all the other VMs | |
| 14:07:09 | sean-k-mooney | yep | |
| 14:07:19 | sean-k-mooney | so im not saying your silter wont work | |
| 14:07:25 | mnaser | oh yeah no it does work its just.. eww. | |
| 14:07:53 | sean-k-mooney | but if we were to supprot this in nova properly we likely would need to do somethign else to optimise this | |
| 14:08:08 | mnaser | sean-k-mooney: I think maybe an extra kwarg for host_passes to include all of the HostState for all the nodes still eligible in the filter | |
| 14:08:56 | sean-k-mooney | we try not to do that | |
| 14:08:58 | mnaser | so that reduces how much I need to lookup | |
| 14:09:05 | sean-k-mooney | it breaks all out of tree filters when we do | |
| 14:09:10 | sean-k-mooney | not that we technilay supprot those | |
| 14:09:25 | sean-k-mooney | but adding files to the host state object does not break the api | |
| 14:09:31 | mnaser | hmm ok valid | |
| 14:09:45 | sean-k-mooney | so we woudl pass this either via the host_state object or request spec | |
| 14:10:31 | mnaser | I mean if the failure domain concept becomes a little bit more concrete then there are other place we can leverage it in other places to optimize the way its looked up fo rsure | |
| 14:10:53 | mnaser | and maybe just maybe also expose it as a sha'd string in nova's api... but thats stretching my luck :) | |
| 14:11:35 | mnaser | the goal here is to expose this to k8s cluster provisioners and so that the failure domain can be exposed to the user so they can make sure they schedule their pods on nodes with different failure domains | |
| 16:41:56 | sean-k-mooney | mnaser: you asked for feedback :) | |
| 16:58:55 | opendevreview | Merged openstack/nova stable/2024.1: Add iso file format inspector https://review.opendev.org/c/openstack/nova/+/923724 | |
| 16:59:00 | opendevreview | Merged openstack/nova stable/2024.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923878 | |
| 17:28:44 | opendevreview | keerthivasan proposed openstack/nova master: Move nova-manage db purge to nova-audit https://review.opendev.org/c/openstack/nova/+/708783 | |
| 17:44:52 | opendevreview | keerthivasan proposed openstack/nova master: Move nova-manage db purge to nova-audit https://review.opendev.org/c/openstack/nova/+/708783 | |
| 17:57:11 | opendevreview | Merged openstack/nova master: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923924 | |
| 19:24:57 | opendevreview | Jens Harbott proposed openstack/nova master: DNM: Test devstack change https://review.opendev.org/c/openstack/nova/+/923759 | |
| #openstack-nova - 2024-07-12 | |||
| 02:21:55 | opendevreview | melanie witt proposed openstack/nova master: Add config option [quota]strict_unified_limits https://review.opendev.org/c/openstack/nova/+/924025 | |
| 07:32:49 | opendevreview | melanie witt proposed openstack/nova master: Add config option [quota]strict_unified_limits https://review.opendev.org/c/openstack/nova/+/924025 | |
| 07:35:55 | melwitt | sean-k-mooney: ^ POC attempt at the different logic we chatted about the other day | |
| 08:04:53 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923907 | |
| 08:04:54 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923936 | |
| 08:09:01 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.1: fix qemu-img version dependent tests https://review.opendev.org/c/openstack/nova/+/923908 | |
| 08:09:02 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.1: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923937 | |
| 09:38:01 | sean-k-mooney | melwitt: oh cool. after creating that how do you feel about one approch vs the other. no need to reply now but let me know after you get some sleep | |
| 10:09:04 | gibi | sean-k-mooney: could you approve https://review.opendev.org/c/openstack/nova/+/923935 to continue landing the series? | |
| 10:09:48 | gibi | most of the 2023.2 is also on the gate now thanks to elodilles | |
| 10:13:59 | sean-k-mooney | i for got to clice the buttons and only left a commet ... | |
| 10:14:02 | sean-k-mooney | but done now | |
| 10:15:25 | gibi | sean-k-mooney: thanks, could you review the same patch on the older branches? Then I can just ping elodilles when we need the approve | |
| 10:15:50 | sean-k-mooney | already am | |
| 10:17:25 | sean-k-mooney | ok i think im +2 on all the ones i didnt push | |
| 10:27:09 | opendevreview | Merged openstack/nova stable/2023.2: port format inspector tests from glance https://review.opendev.org/c/openstack/nova/+/923727 | |
| 10:27:14 | opendevreview | Merged openstack/nova stable/2023.2: Reproduce iso regression with deep format inspection https://review.opendev.org/c/openstack/nova/+/923728 | |
| 11:18:47 | frickler | gibi: sean-k-mooney: gate failure in openstacksdk-functional-devstack on https://review.opendev.org/c/openstack/nova/+/923729 . if you can double check that it is unrelated, I'd submit it right back into gate again | |
| 11:20:48 | opendevreview | Merged openstack/nova stable/2024.1: Stabilize iso format unit tests https://review.opendev.org/c/openstack/nova/+/923935 | |
| 11:20:54 | opendevreview | Merged openstack/nova stable/2023.1: port format inspector tests from glance https://review.opendev.org/c/openstack/nova/+/923731 | |
| 11:21:00 | opendevreview | Merged openstack/nova stable/2023.1: Reproduce iso regression with deep format inspection https://review.opendev.org/c/openstack/nova/+/923732 | |
| 11:41:53 | vicent | Good morning! I am using sriov, I have two PFs with two VFs each. The PFs are connected to different networks, so when I create a neutron port with type direct, I need a way to map that port so it uses one of the VFs of a specific PF. I found this document https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html which uses traits, but I need to set | |
| 11:41:59 | vicent | the trait on the port, not on the flavor. Basically, how can I configure the VFs of different PF in pools, so I have control to which VF pool is used for which network? I managed to get my PFs as resource providers on placement and I my ports get correctly bound to the VFs, but I can't control the mapping to a specific custom trait. How does nova request a specific resource provider for the port? | |
| 11:42:05 | vicent | Is there a way to do what I am trying to do? | |
| 11:43:29 | sean-k-mooney | vicent: the only way to do that today is to use a differnt neutron phsynet for each PF | |
| 11:44:04 | sean-k-mooney | there is no support for anti affintiy or vf bonding in openstack today | |
| 11:44:19 | sean-k-mooney | some have tried to hack it in without enableing it in nova or neutron | |
| 11:44:29 | sean-k-mooney | melonox have some vf lag supprot | |
| 11:44:39 | sean-k-mooney | but its not officaly supproted in nova or neutorn | |
| 11:45:17 | vicent | I can't use physnet in my case :S | |
| 11:45:31 | vicent | Do you have a link to the mellanox resource? | |
| 11:45:37 | sean-k-mooney | then unfortunetly you cant do this in openstack | |
| 11:46:11 | sean-k-mooney | the proibelme with the melxons approch si there is no awarenss of it in nova ans no schduler supprot as a result | |
| 11:46:22 | sean-k-mooney | there is alos no way to request it as an end user | |
| 11:46:38 | sean-k-mooney | it done out fo band bay howe you confirg the host hardware | |
| 11:46:43 | vicent | ok, then it won't work for me either | |
| 11:47:07 | sean-k-mooney | https://www.stackhpc.com/vflag-kayobe.html | |
| 11:49:04 | vicent | does nova have any plugin/extension mechanism that could be used to control that? | |
| 11:49:16 | sean-k-mooney | no | |
| 11:50:23 | vicent | so if I wanted to get that, I would need to modify nova directly... Ok | |
| 11:50:30 | sean-k-mooney | as i said the only way to do anti affinity at the pf/vf level is with physnets | |
| 11:51:14 | sean-k-mooney | yes and form an upstream poitn of view we do not plann to supprot this until neutron has a bonding api similer to trunk ports | |
| 11:51:37 | sean-k-mooney | which was discuss a few years ago but no one is currently working on that | |
| 11:51:44 | vicent | My use case is not for bonding | |
| 11:52:29 | sean-k-mooney | well we also don thave any kind of port grouping or anti affintiy api in neutron that can be used moddel the relationship | |
| 11:52:38 | sean-k-mooney | that really the gap | |
| 11:53:09 | vicent | It is more about scheduling and resource selection, not grouping or anti-affinity | |
| 11:53:31 | sean-k-mooney | right so pci in palcement does nto supprot neutorn prots righ tnow | |
| 11:53:38 | sean-k-mooney | that is planned for a future release | |
| 11:53:39 | vicent | I want to be able to enforce a specific PF on my port without physnet. | |
| 11:54:06 | sean-k-mooney | vicent: well that is somethign we explictly dont support | |
| 11:54:32 | sean-k-mooney | its a disging goal ot not allow you to directly choose the PF on a host | |
| 11:54:46 | sean-k-mooney | you can poticaly abuse traits to support that | |
| 11:55:03 | vicent | well, not the PF, but the any VFs of that PF | |