| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-27 | |||
| 16:36:56 | justas_napa | for that we would like to add a VIF type corresponding to Napatech SmartNIC | |
| 16:37:08 | justas_napa | ein a simmilar fashion like Netronomes Agillio | |
| 16:37:33 | bauzas | do you work with Neutron ? | |
| 16:37:33 | justas_napa | But at the same time we do not need a new VNIC type | |
| 16:37:38 | justas_napa | Yes | |
| 16:37:46 | bauzas | so I guess you also have a neutron spec | |
| 16:38:15 | justas_napa | We have extremely small update to Neutron, but yes, we will do a Neutron spec as well | |
| 16:38:55 | bauzas | this doesn't look a lot of change for nova, right? | |
| 16:39:11 | bauzas | we already support *some* smartnic experiments | |
| 16:39:13 | justas_napa | no, I think it's less than 50 lines | |
| 16:40:13 | bauzas | justas_napa: I guess you already know about what Nova supports by the Wallaby release ? | |
| 16:40:16 | justas_napa | We will publish all changes to Nova and Os-Vif on OpenDev in the next few days | |
| 16:40:33 | justas_napa | bauzas What do you mean? | |
| 16:41:08 | bauzas | sorry, wrong release | |
| 16:41:13 | bauzas | justas_napa: I was talking of https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html | |
| 16:41:39 | bauzas | oh wait no, my bad | |
| 16:41:45 | bauzas | again, wrong spec | |
| 16:42:15 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/integration-with-off-path-network-backends.html | |
| 16:42:57 | bauzas | anyway, I just pointed out the existing specs | |
| 16:43:10 | bauzas | afaics, this is just a review ask | |
| 16:43:28 | bauzas | so, we'll review it | |
| 16:43:43 | bauzas | justas_napa: would you want to discuss your topic during the PTG ? | |
| 16:43:51 | bauzas | in case we have concerns | |
| 16:43:52 | justas_napa | Sure, I can do that | |
| 16:44:15 | bauzas | thanks | |
| 16:44:19 | bauzas | if you can't do, no worriezs | |
| 16:44:27 | justas_napa | Re: off-path networking backed - we are in the progress of integrating Intel Big Spring Canyon platform to du just that | |
| 16:44:32 | bauzas | justas_napa: and you don't need to be on the whole PTG times | |
| 16:44:57 | bauzas | justas_napa: we could just ping you when we are at the topic | |
| 16:45:01 | justas_napa | sure | |
| 16:45:15 | bauzas | thanks | |
| 16:45:30 | justas_napa | So what's the path from here: 1. We puiblish code changes and ask for review in channel? | |
| 16:45:35 | justas_napa | and then PTG? | |
| 16:45:38 | bauzas | anyone having questions or thoughts for this ? | |
| 16:45:49 | bauzas | justas_napa: indeed | |
| 16:45:56 | justas_napa | cool. | |
| 16:46:17 | bauzas | we will review your spec first, but if you have implementation changes, that would be nice | |
| 16:46:29 | bauzas | as if we have concerns, we could just look at your changes | |
| 16:46:36 | justas_napa | Yes, we have implemetation changes as well, since we are running it internally anyway | |
| 16:46:38 | gibi | I agree with bauzas | |
| 16:46:40 | bauzas | to understand what you need | |
| 16:47:21 | justas_napa | btw - is it OK to bring one more topick to PTG. Specifically, how to support Packed Ring Libvirt option (packed=on) and which project should implement that. | |
| 16:47:27 | bauzas | justas_napa: I guess you know how to depend on neutron changes ? | |
| 16:47:38 | bauzas | justas_napa: yeah, no worries | |
| 16:47:46 | bauzas | the PTG is here for discussing | |
| 16:48:08 | justas_napa | Yes, I'm aware that we need changes in Nova *and* Neutron to make this work | |
| 16:48:18 | bauzas | justas_napa: my only concern is about how to test your nova changes if you need an os-vif release | |
| 16:48:33 | bauzas | as you can't Depends-On | |
| 16:48:52 | bauzas | gibi: correct for os-vif, right? | |
| 16:49:17 | bauzas | I meant, can we depend-on os-vif patches ? | |
| 16:49:29 | gibi | I'm not sure either | |
| 16:49:49 | justas_napa | I'll put this also as TBD item for our dev team | |
| 16:49:59 | bauzas | justas_napa: do you understand about my question ? | |
| 16:50:18 | bauzas | justas_napa: if you upload three changes, each for a different repo | |
| 16:50:32 | gibi | bauzas: it depends on how the zuul job is set up. Are we testing with released os-vif lib or are we taking master all the time? | |
| 16:50:37 | bauzas | justas_napa: in general, you can depend a gerrit cvhange on another one | |
| 16:50:58 | justas_napa | Yes, I understand the issue of cross-project dependancy | |
| 16:51:14 | gibi | bauzas: if the former, then the a DNM nova patch on top of the nova series could configure zuul to use the later method + add a Depends-On to the os-vig patch | |
| 16:51:18 | justas_napa | and that our change is not atomic across the projects | |
| 16:51:24 | bauzas | justas_napa: but here, the question is that for some libraries, we maybe use a specific release and not using master | |
| 16:51:52 | bauzas | gibi: yeah, that would work | |
| 16:52:06 | bauzas | justas_napa: do you understand what gibi is explaining ? | |
| 16:52:08 | justas_napa | OK, I understand the issue, but I'm not sure I can offer a solution. | |
| 16:52:44 | bauzas | justas_napa: well, we maybe have a solution, that's the point | |
| 16:52:45 | justas_napa | One way is to use our ci/cd setup where we runn all regression tests and have control of releases of all projects | |
| 16:53:21 | bauzas | anyway, we should be discussing this in the spec | |
| 16:53:43 | bauzas | justas_napa: are you saying you could provide a third-party CI for nova/neutron ? :D | |
| 16:53:58 | bauzas | this would be lovely | |
| 16:54:16 | justas_napa | not sure what you mean 3rd party | |
| 16:54:44 | justas_napa | but we have our own ci/cd pipeline running integration tests with our changes | |
| 16:54:55 | bauzas | ok, then we'll discuss this in the spec and we can also provide you some links if you want | |
| 16:55:09 | justas_napa | to ensure we do not break anything with our OS patches | |
| 16:55:19 | bauzas | justas_napa: are you running tempest tests ? | |
| 16:55:22 | justas_napa | yes | |
| 16:55:44 | bauzas | cool, then that's something we need to discuss then | |
| 16:55:55 | bauzas | anyway, I guess we're done about your topic | |
| 16:56:01 | bauzas | we'll continue discussing | |
| 16:56:21 | justas_napa | sure, thanks for all questions and comments | |
| 16:56:25 | bauzas | folks, any other item to bring before we end the meeting ? | |
| 16:56:58 | bauzas | looks not | |
| 16:57:01 | bauzas | thanks all | |
| 16:57:04 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.log.html | |
| 16:57:04 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.txt | |
| 16:57:04 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.html | |
| 16:57:04 | opendevmeet | Meeting ended Tue Sep 27 16:57:04 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:04 | bauzas | #endmeeting | |
| 16:57:08 | elodilles | thanks o/ | |
| 16:58:35 | gibi | o/ | |
| 18:45:22 | JayF | bauzas: o/ We need to meet up and discuss timing for joint Ironic<>Nova PTG session. | |
| 18:45:42 | JayF | bauzas: unsure what timezone you're in, but if you're asleep/AFK right now, just DM me and we can figure it out async | |
| 18:59:56 | stephenfin | JayF: bauzas is in France so CET. You'll catch him tomorrow | |
| 19:00:22 | JayF | ack; I figured, not a big deal, took me a couple of days to voluntell the right people I needed them in that session and get scheduling deets :D | |
| #openstack-nova - 2022-09-28 | |||
| 06:10:44 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check for VM snapshot fail while quiesce https://review.opendev.org/c/openstack/nova/+/852171 | |
| 07:00:18 | bauzas | JayF: ping me when you're back if you want, sure | |
| 10:10:38 | opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Bump min oslo.concurrencty to >= 5.0.1 https://review.opendev.org/c/openstack/nova/+/859421 | |
| 10:29:10 | damiandabrowski | hey folks, I noticed that if compute node already exceeds its overcommit ratios, it's not possible to migrate VMs out of it | |
| 10:29:29 | damiandabrowski | it makes no sense for me and it should be considered as a bug, but maybe there is some reason behind it? | |
| 10:29:31 | damiandabrowski | https://paste.openstack.org/raw/byjHufprWu3hwDFPSKAD/ | |
| 10:37:37 | gibi | damiandabrowski: the reason is that if you the compute is already exceeds overcommit then it cannot have new allocations. And the migration needs to move the instance allocation to the migration_uuid in placement and that would require a new allocation even if the total usage would not change. | |
| 10:37:54 | gibi | what you can do is | |