| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-08-31 | |||
| 10:30:20 | kevinz | kashyap: bauzas: Thanks! Really appreciated :-) | |
| 10:54:50 | opendevreview | Merged openstack/nova master: nova-manage: Introduce volume show, refresh, get_connector commands https://review.opendev.org/c/openstack/nova/+/800634 | |
| 10:54:54 | opendevreview | Merged openstack/placement master: Refactor consumer type methods for readability https://review.opendev.org/c/openstack/placement/+/806035 | |
| 10:55:06 | opendevreview | Merged openstack/nova stable/wallaby: Reduce mocking in test_reject_open_redirect for compat https://review.opendev.org/c/openstack/nova/+/803092 | |
| 11:21:02 | gibi | /12 | |
| 11:46:50 | opendevreview | Balazs Gibizer proposed openstack/placement master: Add reproducer for Project creation race bug https://review.opendev.org/c/openstack/placement/+/806730 | |
| 11:47:47 | gibi | melwitt, bauzas: ^^ it is the reproducer to the issue octavia folks reported today. I could not create a real race in the func test env so I cheated a but | |
| 11:47:50 | gibi | bit | |
| 12:22:51 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Address nits for configurable-instance-hostnames series https://review.opendev.org/c/openstack/nova/+/806735 | |
| 12:24:02 | gibi | sean-k-mooney: what is the expected behavior of a sriov interface attach in an env where the PCI devices are part of numa0 but the instance cpus are part of numa1? | |
| 12:25:11 | sean-k-mooney | it depend on if the vm has a numa toplogy and the numa policy | |
| 12:25:25 | sean-k-mooney | if the vm has no numa toplogy its fine it should boot | |
| 12:25:44 | sean-k-mooney | if it it has cpu pinning it should not boot unless you use pci_numa_toplogy=prefer | |
| 12:26:02 | sean-k-mooney | which will prefer a host where affinity can be acive but not enforce it on the host | |
| 12:26:31 | gibi | sean-k-mooney: what about pci_numa_toplogy=legacy? | |
| 12:27:21 | sean-k-mooney | legacy means if the device report numa info its enforced but if it does not it allowed regardless of the cpu selected | |
| 12:27:53 | sean-k-mooney | so legacy which is the default rquired numa affinity if we have numa info for the device and the cpus/memory | |
| 12:28:20 | gibi | OK, so In my internal case the VM has topology due to cpu pinning and they not specify policy so they get the legacy one | |
| 12:28:33 | sean-k-mooney | yep | |
| 12:29:00 | gibi | and the pci device has numa info so the basically get strict affinity | |
| 12:29:38 | gibi | with hw:pci_numa_affinity_policy=preferred they would get best effort affinity | |
| 12:29:39 | sean-k-mooney | yep | |
| 12:29:52 | sean-k-mooney | we have test for this in whitebox by the way | |
| 12:29:54 | sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/api/compute/test_sriov.py#L221-L432 | |
| 12:30:17 | sean-k-mooney | we also have func tests for this i think in nova | |
| 12:30:38 | sean-k-mooney | preffer is basically currenlty implemtned as a weigher | |
| 12:30:51 | sean-k-mooney | i have a very long running todo to make prefer prefer numa nodes on the comptue too | |
| 12:31:00 | sean-k-mooney | its a simple chagne just never got around to do it | |
| 12:32:17 | sean-k-mooney | to implement prefer on the compute node we litrally just need an else on https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L2201-L2205 that sorts in teh reverse order | |
| 12:33:24 | sean-k-mooney | gibi: for backwards compatiablity reasons we made legacy the default but prefer is arguable a more user friendly default | |
| 12:33:34 | gibi | ack thanks | |
| 12:34:04 | gibi | sean-k-mooney: do we have the per port numa affinity supported by nova? | |
| 12:34:19 | gibi | i.e. the nova side of https://bugs.launchpad.net/neutron/+bug/1886798 | |
| 12:34:26 | sean-k-mooney | yes | |
| 12:34:37 | sean-k-mooney | i need to check which release but we do in wallaby | |
| 12:34:41 | sean-k-mooney | maybe victoria | |
| 12:35:00 | gibi | so for interface attach the user could set the policy on the port if the instace was booted without the flavor extra sepc | |
| 12:35:03 | gibi | spec | |
| 12:35:07 | sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/wallaby/implemented/port-scoped-sriov-numa-affinity.rst | |
| 12:35:15 | gibi | cool, thanks | |
| 12:35:59 | sean-k-mooney | ya i think we covered that usecase when you added sriov attach support too | |
| 12:37:02 | sean-k-mooney | both feature were added in wallaby and im 99% sure that we pass the posicy when trying to claim the pci device on attach and will reject it if the numa affintiy cant be achived | |
| 12:37:14 | sean-k-mooney | but you can relax the policy with the neutron port | |
| 12:37:29 | sean-k-mooney | so the vm can default to legacy or strict and then you can add a port with prefer | |
| 12:39:57 | gibi | cool. I do remember passing policy around in sriov attach impl | |
| 12:40:31 | sean-k-mooney | yep we do https://github.com/openstack/nova/blob/649b2452da07c25e1251c6185552278f91b7c517/nova/compute/manager.py#L7788-L7794 | |
| 12:40:53 | sean-k-mooney | hehe ya was just finding that in the code | |
| 12:43:06 | sean-k-mooney | that gets the flavor/image policy then we override that with the port policy if set https://github.com/openstack/nova/blob/649b2452da07c25e1251c6185552278f91b7c517/nova/network/neutron.py#L2023-L2026 | |
| 12:43:33 | sean-k-mooney | https://github.com/openstack/nova/blob/649b2452da07c25e1251c6185552278f91b7c517/nova/network/neutron.py#L2084 | |
| 12:43:50 | sean-k-mooney | https://github.com/openstack/nova/blob/649b2452da07c25e1251c6185552278f91b7c517/nova/network/neutron.py#L2162-L2164 | |
| 12:44:13 | sean-k-mooney | gibi: i rememebr discussing the precednece of these two during the spec review | |
| 12:47:15 | opendevreview | sean mooney proposed openstack/nova master: Add 'hw:vif_multiqueue_enabled' flavor extra spec https://review.opendev.org/c/openstack/nova/+/792356 | |
| 12:47:16 | opendevreview | sean mooney proposed openstack/nova master: Move 'hw:pmu', 'hw_pmu' parsing to nova.virt.hardware https://review.opendev.org/c/openstack/nova/+/792364 | |
| 12:47:16 | opendevreview | sean mooney proposed openstack/nova master: docs: Document virtio-net multiqueue https://review.opendev.org/c/openstack/nova/+/792362 | |
| 12:48:06 | sean-k-mooney | stephenfin: i have adressed my nits regarding the acidental cahnge form 403 to 500 and resolved the merge conflict otherwise this is as you left it | |
| 12:48:42 | sean-k-mooney | i think those should be good to merge now if people have time to review | |
| 12:59:44 | kashyap | kevinz: Looked at it; I see you've also done real tests with it. I don't see anything glaring in there. Also the conditional is AArch64 specific. Thx for reworking. | |
| 13:02:10 | bauzas | sean-k-mooney: correct me if I'm wrong, but I see a last revision of generic mdevs that is only due for fixing pep8 mypy issues because we were not explicitely returning None ? | |
| 13:02:36 | bauzas | plus the fact you moved the documentation bit out of the last change into a specific WIP change, right? | |
| 13:02:37 | sean-k-mooney | bauzas: yes | |
| 13:03:22 | sean-k-mooney | stephenfin: was ok with adressing the doc update in a seperate change so suggested we split it out to not block the feature | |
| 13:03:33 | sean-k-mooney | since the doc update can happen after FF | |
| 13:04:23 | sean-k-mooney | bauzas: effectivly what stephenfin would like is if we have a stuf file that explains vgpu are now implemented in terms of generic mdevs and then links to mdev doc | |
| 13:04:45 | sean-k-mooney | bauzas: if we want to have specific vgpu docs we can keep them int vgpu doc | |
| 13:05:26 | sean-k-mooney | bauzas: but ya i did not actully change any of your codes functionality form where you left it just the mypy update | |
| 13:08:49 | bauzas | sean-k-mooney: no worries at all, my question was just for understanding the touched bits, and to make sure I wasn't missing crucial bits | |
| 13:09:06 | bauzas | sean-k-mooney: thanks for having followed up while I was working on my tan | |
| 13:09:38 | sean-k-mooney | i ment to get to it sooner but i did not see the pep8 failure until recently | |
| 13:09:44 | bauzas | (which was a difficult effort as I discovered to having traveled to the worst raining place in France apparently) | |
| 13:10:00 | bauzas | a perfect Irish weather for the first week | |
| 13:13:14 | sean-k-mooney | haha we hit 27+ a few days while you were off | |
| 13:13:47 | gibi | now that is perfect ^^ :) | |
| 13:14:17 | kevinz | kashyap: Thanks a lot! Good to hear that! | |
| 13:14:33 | sean-k-mooney | its been a pretty good summber all things considered in ireland this year at least on teh weather front | |
| 13:15:06 | bauzas | sean-k-mooney: are you honestly saying I got an irish weather while you were getting a mediterrean weather ? | |
| 13:15:15 | bauzas | life is unfair | |
| 13:15:24 | sean-k-mooney | very much so | |
| 13:15:48 | bauzas | pro-tip : we usually joke about french Britain rainy weather | |
| 13:16:10 | bauzas | but please reconsider the basque country as more wet than britain :) | |
| 13:16:11 | sean-k-mooney | with that said my tomatoes got hit by blight last week and are all starting to die but we still got some of the harvest | |
| 13:17:10 | sean-k-mooney | its the result of having heat then lots of humitity for 2 and ah half weeks | |
| 13:17:15 | bauzas | sean-k-mooney: hah, I'm jealous | |
| 13:17:28 | bauzas | we got a ridiculous harvest this year for our tomatoes | |
| 13:18:37 | bauzas | but, let me ask one question : any series to look at now besides kevinz's ask ? | |
| 13:18:46 | sean-k-mooney | i think we have got like 2-3 kg form 20-25 plants which is not greate but i know some have just had there entire lot of plants wiped out | |
| 13:18:53 | bauzas | gibi: I guess I'm all done for you with your pps series, right? | |
| 13:18:59 | sean-k-mooney | bauzas: https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 13:19:01 | opendevreview | Federico Ressi proposed openstack/nova master: [WIP] Investigate on Nova quota limits problem https://review.opendev.org/c/openstack/nova/+/806683 | |
| 13:19:05 | sean-k-mooney | i just put a few on the meeting adgenda | |
| 13:19:36 | sean-k-mooney | bauzas: the review priortiy lable merged a few days ago so im suggeesting we start using that to track them | |
| 13:19:39 | gibi | bauzas: I have my reviews for the pps so you can focus on other things | |
| 13:20:13 | bauzas | sean-k-mooney: excellent | |
| 13:20:46 | bauzas | gibi: that's the question I'm asking, I don't know what other things to do | |
| 13:20:55 | opendevreview | Federico Ressi proposed openstack/nova master: [WIP] Investigate on Nova quota limits problem https://review.opendev.org/c/openstack/nova/+/806683 | |
| 13:21:21 | bauzas | unified limits would get my interest, but we're two days from FF, and this is unfortunate I didn't had time to look at it before | |
| 13:21:25 | gibi | bauzas: things in NeedsCodeReview state are a good candidates https://launchpad.net/nova/+milestone/xena-3 | |
| 13:21:39 | bauzas | will find candidates, no worries | |
| 13:21:54 | gibi | ack | |
| 13:22:19 | sean-k-mooney | oh thats a good point | |
| 13:22:57 | gibi | and now I remember to update the meeting agenda ... :D | |