Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-09-27
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 bauzas #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.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 Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.log.html
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
10:38:19 gibi i) increase the allocation ratio temporarily to the level where the usage not exceeds it
10:38:25 gibi ii) migrate the workload out
10:38:41 gibi iii) revert the allocation ratio to the original level
10:39:27 damiandabrowski thanks, i'll do that
10:39:31 damiandabrowski so you don't consider it as a bug, right?
10:40:27 gibi you exceeded the overallocation so you are in a not supported state I would say
10:41:28 damiandabrowski okok, thanks for clarification
12:17:52 opendevreview Oleksii Butenko proposed openstack/os-vif master: Add new os-vif `network` property https://review.opendev.org/c/openstack/os-vif/+/859574
12:19:53 jkulik damiandabrowski: FYI, we have a patch downstream in our Placement to allow switching resources on overused providers, so migrations off should still be possible: https://github.com/sapcc/placement/commit/2691056d6fa3e7db0cf9966b082af51ae6b5dda9
12:20:29 jkulik use at your own risk, though
12:29:45 damiandabrowski oh that's convenient, thanks

Earlier   Later