| opendevreview | melanie witt proposed openstack/nova master: Add hw_ephemeral_encryption_secret_uuid image property https://review.opendev.org/c/openstack/nova/+/870935 | 00:46 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase https://review.opendev.org/c/openstack/nova/+/870936 | 03:47 |
| opendevreview | Merged openstack/nova stable/2023.1: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900306 | 10:45 |
| opendevreview | Merged openstack/nova stable/2023.1: Fix rebuild compute RPC API exception for rolling-upgrades https://review.opendev.org/c/openstack/nova/+/900336 | 12:16 |
| opendevreview | Merged openstack/nova stable/2023.1: hyperv: Mark driver as experimental https://review.opendev.org/c/openstack/nova/+/899159 | 12:16 |
| opendevreview | Tobias Urdin proposed openstack/nova stable/yoga: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/898554 | 13:47 |
| *** jakob is now known as grandchild | 13:57 | |
| bauzas | sean-k-mooney: thanks for have explained my change https://review.opendev.org/c/openstack/nova/+/899625 you understood it | 14:19 |
| bauzas | sean-k-mooney: I'll provide a functest by the change too (if I can) before removing the WIP | 14:20 |
| bauzas | so I hope people will better understand the change | 14:20 |
| sean-k-mooney | so i descirbed what the algoritim shoudl do i didnt have time to fully read the code and determinif your change actully implemnted that | 14:21 |
| *** ravlew is now known as Guest7716 | 14:21 | |
| tobias-urdin | perhaps possible to get https://review.opendev.org/c/openstack/nova/+/898554 in before yoga release (that is the last release before eol?) https://review.opendev.org/c/openstack/releases/+/899605 | 14:22 |
| bauzas | sean-k-mooney: oh no, we haven't said to have a specific change for SRIOV | 14:27 |
| bauzas | sean-k-mooney: we just said to limit the number of RPs by the limit | 14:27 |
| bauzas | this is a simple change that doesn't need to change the behaviour so we can backport it | 14:28 |
| bauzas | and we don't need to reshape | 14:28 |
| sean-k-mooney | right i described 2 viable algortiims one that requries a reshape and one that does not | 14:28 |
| sean-k-mooney | both only ever advertise the number of vgpus that can be created | 14:28 |
| sean-k-mooney | assuming max_isntances is defiend | 14:29 |
| sean-k-mooney | and wont require removal at runtime | 14:29 |
| bauzas | my change can also work with non-SRIOV GPUs | 14:29 |
| bauzas | that's the fact | 14:29 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/899625/6/nova/tests/unit/virt/libvirt/test_driver.py#26367 is a unittest explaining what we would pass | 14:30 |
| opendevreview | ribaudr proposed openstack/nova master: Allow config to support virtiofs (driver) https://review.opendev.org/c/openstack/nova/+/886522 | 14:30 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | 14:30 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Deletion of associated share mappings on instance deletion https://review.opendev.org/c/openstack/nova/+/881472 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/854824 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/860285 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part) https://review.opendev.org/c/openstack/nova/+/860287 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/860288 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Allow to mount manila share using Cephfs protocol https://review.opendev.org/c/openstack/nova/+/883862 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Check shares support (compute manager) https://review.opendev.org/c/openstack/nova/+/885751 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add share lock/unlock and restrict visibility https://review.opendev.org/c/openstack/nova/+/890340 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Check shares support (only API exception) https://review.opendev.org/c/openstack/nova/+/885752 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (API) https://review.opendev.org/c/openstack/nova/+/836830 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Check shares support (API) https://review.opendev.org/c/openstack/nova/+/850499 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/885753 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | 14:31 |
| opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | 14:31 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Allow enabling cpu_power_management with 0 dedicated CPUs https://review.opendev.org/c/openstack/nova/+/901188 | 14:36 |
| bauzas | reminder : nova meeting in 52 mins here | 15:08 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Nov 21 16:00:17 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | hey folks | 16:00 |
| bauzas | aloha | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| Uggla_ | o/ | 16:01 |
| grandchild | hi | 16:01 |
| bauzas | awaiting a few more people | 16:01 |
| gibi | o/ | 16:01 |
| sean-k-mooney | o/ | 16:01 |
| elodilles | o/ | 16:02 |
| bauzas | okay, let's start | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 37 new untriaged bugs (+5 since the last meeting) | 16:03 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
| bauzas | auniyal6: any bug you wanted to raise ? | 16:03 |
| bauzas | looks like he's offline | 16:04 |
| bauzas | I'll take the baton this week | 16:04 |
| bauzas | #info bug baton is bauzas | 16:04 |
| bauzas | moving on | 16:04 |
| bauzas | #topic Gate status | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:04 |
| bauzas | we had a fun gate blocker this week | 16:04 |
| sean-k-mooney | the tooz thing? | 16:05 |
| bauzas | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/L72QU3SR2VFVYOFXVYH74V7HGMQ3YJRU/ | 16:05 |
| bauzas | yeah | 16:05 |
| sean-k-mooney | you know we also use tooz in the ironic virt driver | 16:05 |
| bauzas | anyway, we skipped the oslo tooz release | 16:06 |
| sean-k-mooney | so its not just used by cinder | 16:06 |
| bauzas | so now the tooz community needs to discuss how to support both etcd versions* | 16:06 |
| bauzas | sean-k-mooney: sure but the gate was failing due to the cinder API issue | 16:06 |
| sean-k-mooney | they could for now just swap to using hte memcached drier instead of ectd | 16:07 |
| sean-k-mooney | in the gate | 16:07 |
| bauzas | it's no longer a nova problem :) | 16:07 |
| sean-k-mooney | :) | 16:07 |
| bauzas | anyway | 16:07 |
| bauzas | fwiw, now we have back a nova-emulation job issue https://zuul.openstack.org/builds?job_name=nova-emulation&project=openstack/nova | 16:08 |
| bauzas | chateaulav: around ? | 16:08 |
| bauzas | oh wait | 16:08 |
| bauzas | this is not against master | 16:08 |
| sean-k-mooney | ya so the emulation job i think is running on one of the stable branches | 16:10 |
| bauzas | anyway, we'll see how this goes next week | 16:10 |
| sean-k-mooney | which it should not be | 16:10 |
| bauzas | sean-k-mooney: well, it's checking for yoga | 16:10 |
| sean-k-mooney | its in check on yoga but it should only be in perodic-weekly | 16:11 |
| bauzas | so probably in the next month, shouldn't be a problem :p | 16:11 |
| sean-k-mooney | right we just forgot to move it on that branch | 16:11 |
| sean-k-mooney | sure | 16:11 |
| bauzas | we'll see | 16:11 |
| bauzas | moving on | 16:11 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:12 |
| bauzas | #topic Release Planning | 16:12 |
| bauzas | #link https://releases.openstack.org/caracal/schedule.html | 16:12 |
| bauzas | #info Nova deadlines currently on review https://review.opendev.org/c/openstack/releases/+/877094 | 16:12 |
| bauzas | I just hope the release cores will accept it quickly | 16:12 |
| sean-k-mooney | its alredy merged | 16:12 |
| bauzas | wow | 16:13 |
| bauzas | haven't seen it | 16:13 |
| sean-k-mooney | was that the right link | 16:13 |
| sean-k-mooney | that was for bobcat | 16:13 |
| bauzas | doh | 16:13 |
| bauzas | #undo | 16:13 |
| opendevmeet | Removing item from minutes: #info Nova deadlines currently on review https://review.opendev.org/c/openstack/releases/+/877094 | 16:13 |
| sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/901547 | 16:13 |
| bauzas | #info Nova deadlines currently on review https://review.opendev.org/c/openstack/releases/+/901547 | 16:14 |
| sean-k-mooney | it has a -1 for elod specfreeze is wrong | 16:14 |
| bauzas | okay, just saw elodilles's question | 16:14 |
| elodilles | o:) | 16:14 |
| bauzas | I'll look at it | 16:14 |
| sean-k-mooney | elodilles:++ sorry that should read from not for | 16:14 |
| bauzas | and yeah you're right | 16:14 |
| bauzas | elodilles: indeed was wrong, should be milestone-2 for spec freeze, my bad :) | 16:15 |
| elodilles | np :) | 16:15 |
| bauzas | I'll upload a new rev | 16:15 |
| elodilles | thx | 16:15 |
| bauzas | #info Caracal-2 (and spec freeze) milestone in 7 weeks | 16:16 |
| bauzas | as a reminder, we'll have another spec review day | 16:16 |
| bauzas | now, I have a question | 16:17 |
| bauzas | we said necxt week that we could add a caracal-1 tag for nova | 16:17 |
| bauzas | but then I looked at all the releases we did from yoga | 16:17 |
| bauzas | and none of them have any milestone tag | 16:18 |
| bauzas | hence my question | 16:18 |
| bauzas | should we create a specific milestone for Nova and Placement? | 16:18 |
| bauzas | I don't think so | 16:18 |
| sean-k-mooney | we are not required to create them. we are just required to have 1 rlease before the final release | 16:18 |
| sean-k-mooney | so the RC-1 release covers that | 16:18 |
| bauzas | this is rc1 | 16:18 |
| bauzas | yeah | 16:18 |
| sean-k-mooney | i dont personlly think milestone release make sense for nova | 16:18 |
| bauzas | and I very quickly looked at cinder, they don't add a milestone too | 16:18 |
| sean-k-mooney | or non lib projects | 16:19 |
| bauzas | yup | 16:19 |
| elodilles | no need for Caracal-1 (.b01) release (which is not rc1) | 16:19 |
| elodilles | for nova & placement | 16:19 |
| elodilles | imo | 16:19 |
| bauzas | the only usecase would be for operators if they want to test milestones | 16:19 |
| elodilles | (it's just a possibility, but we don't need) | 16:19 |
| bauzas | but we haven't had any operators doing this from a long time | 16:19 |
| bauzas | okay | 16:19 |
| sean-k-mooney | they could just deploy a commit at that point | 16:20 |
| sean-k-mooney | googing though the release process for that has very little return | 16:20 |
| sean-k-mooney | we do it for libs since we do not install libs form git as the default | 16:20 |
| bauzas | #action bauzas to not provide a caracal-1 tag actually (compared to what we said on the previous weekly meeting) | 16:20 |
| sean-k-mooney | unlike service projects which we do | 16:20 |
| bauzas | I'm fine | 16:20 |
| bauzas | I just wanted to remove the action item that we agreed last week | 16:21 |
| elodilles | +1 | 16:21 |
| bauzas | I don't know how many people read our meeting minutes but... :) | 16:21 |
| bauzas | anyway, moving on | 16:21 |
| bauzas | #topic Review priorities | 16:21 |
| bauzas | #link https://etherpad.opendev.org/p/nova-caracal-status | 16:21 |
| bauzas | hehe | 16:21 |
| bauzas | so, folks who want to add some bugfixes can now add them in ^ | 16:22 |
| bauzas | we have a specific section | 16:22 |
| bauzas | and cores, please look at this etherpad in order to know what to review | 16:22 |
| gibi | aye sir :) | 16:23 |
| bauzas | nay, I'm not a sir :) | 16:23 |
| gibi | :) | 16:23 |
| bauzas | :D | 16:23 |
| bauzas | #topic Stable Branches | 16:23 |
| bauzas | elodilles: please | 16:24 |
| gibi | monsieur ? :) | 16:24 |
| elodilles | :) | 16:24 |
| elodilles | #info stable gates don't seem blocked | 16:24 |
| elodilles | except now yoga with nova-emulation job :D | 16:24 |
| elodilles | which is almost constantly failing as it looks... | 16:24 |
| sean-k-mooney | do we want to nuke that | 16:24 |
| bauzas | +1 | 16:24 |
| elodilles | is it needed for yoga? | 16:25 |
| sean-k-mooney | we woudl not be running it on unmaintaed anyway | 16:25 |
| sean-k-mooney | and if its brokekn im not sure it worth fixing | 16:25 |
| bauzas | unless we want to unmaintan yoga | 16:25 |
| bauzas | *now* I think | 16:25 |
| sean-k-mooney | elodilles: it was ment to be in perodic-weekly | 16:25 |
| sean-k-mooney | not in check | 16:25 |
| sean-k-mooney | so while it shoudl work its not required | 16:25 |
| elodilles | sean-k-mooney: ACK, i'll check and try to remove from the check pipeline then | 16:25 |
| bauzas | +1 | 16:26 |
| elodilles | bauzas: we'll unmaintain yoga soon, but let's fix that for now if that is possible by eliminating that job o:) | 16:26 |
| elodilles | it's also needed if we want a final release off yoga before it gets unmaintained | 16:27 |
| elodilles | btw, stable releases: | 16:27 |
| elodilles | #info stable release patches still open for review: https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova | 16:27 |
| elodilles | do we still want to wait for patches? | 16:28 |
| elodilles | a couple of stable bug fix have landed meanwhile | 16:28 |
| bauzas | I think I clicked +2 on a yoga change | 16:28 |
| sean-k-mooney | the one from tobias-urdin | 16:29 |
| bauzas | elodilles: what's the deadline ? | 16:29 |
| elodilles | (and that failed due to the nova-emulation) | 16:29 |
| bauzas | sean-k-mooney: yup | 16:29 |
| sean-k-mooney | we should include that in the final release | 16:29 |
| elodilles | bauzas: no strict deadline planned, as we (community) are already late, so just ASAP :) | 16:29 |
| sean-k-mooney | we can quickly update the jobs after the meeting and then recheck the patch | 16:30 |
| elodilles | i mean the EM transition deadline was Nov 2nd, but meanwhile the process is changing and now we need to move to Unmaintained instead | 16:30 |
| elodilles | sean-k-mooney: +1 | 16:31 |
| bauzas | okay | 16:31 |
| elodilles | then the general message then: | 16:31 |
| bauzas | cool enough | 16:31 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:31 |
| elodilles | add here stable gate issues if you encounter one ^^^ | 16:31 |
| elodilles | and that's it i think | 16:32 |
| bauzas | ++ | 16:33 |
| bauzas | moving on then | 16:33 |
| bauzas | #topic Open discussion | 16:34 |
| bauzas | there was one item | 16:34 |
| bauzas | in the agenda | 16:34 |
| bauzas | (fwiesel) vmwareapi driver deprecation/removal: SAP wants to step up provide the resources to keep the driver maintained (CI, tests coverage, code changes, ...?). what would be needed? | 16:34 |
| fwiesel | Hi, that would be me. | 16:34 |
| bauzas | yes indeed | 16:34 |
| fwiesel | So, essentially me and my colleagues talked to our management, and we have the commitment from them to dedicate 1FTE just for upstream work. | 16:35 |
| fwiesel | My understanding is, the most pressing issue would be to have a working stable CI worker for the vmware api, followed by cleanup work, test-coverage, etc... | 16:35 |
| fwiesel | Is that correct? | 16:36 |
| bauzas | we basically deprecated the virt driver by Bobcat | 16:36 |
| sean-k-mooney | and have someone work basically fultime on maintining it | 16:37 |
| bauzas | and we explained the reasons in the relnotes | 16:37 |
| bauzas | https://docs.openstack.org/releasenotes/nova/2023.2.html#deprecation-notes | 16:37 |
| sean-k-mooney | fwiesel: for context this would be the tird time that someone has commited to maintianing that ci and working upstream to maintian the vmware dirver | 16:37 |
| bauzas | "The vmwareapi driver is marked as experimental and may be removed in a future release. The driver is not tested by the OpenStack project and does not have a clear maintainer." | 16:38 |
| fwiesel | Well, I hope that we can step up to be the clear maintainer. And I hope we are not held responsible for the actions of others. | 16:39 |
| sean-k-mooney | we coudl delay the removal for a short period fo time to have you setup the ci but honestly i would prefer to proceed witht he removal and had hoped it woudl have merged already | 16:39 |
| bauzas | the problem here is that most of the times, someone pops up when we are about to delete a virt driver, asks us to not remove it, tells us we will have a 3rd-party CI for a long time, but then after a few months, disappears while the CI job has problems | 16:39 |
| bauzas | this is really a matter of trusting people and companies | 16:39 |
| bauzas | in the maintime, some users think they can use that virt driver and find some problems | 16:40 |
| gibi | fwiesel: what woudl be your timeline setting up a the CI? | 16:40 |
| opendevreview | Elod Illes proposed openstack/nova stable/yoga: Remove nova-emulation from check pipeline of Yoga https://review.opendev.org/c/openstack/nova/+/901604 | 16:41 |
| bauzas | this is why we now say those kind of drivers are experimental | 16:41 |
| grandchild | hi, also from SAP here, and we understand the lack of trust. not much we can say to that now, we'll have to show our work first. | 16:42 |
| grandchild | the issue is exactly the time frame for us to set up a CI while you (understandably) go ahead with removal. | 16:42 |
| fwiesel | Sure, trust must be earned, so we can't expect you do that right away. And I can't expect the driver not to be removed considering current timelines. But hopefully we can find a way forward to re-integrate it then later under some better circumstances. | 16:42 |
| bauzas | fwiesel: grandchild: thanks for replying | 16:43 |
| bauzas | so, I have a question | 16:43 |
| bauzas | say you need some time for running a 3rd-party CI | 16:43 |
| bauzas | and you need to reply to gibi on that | 16:43 |
| bauzas | then, | 16:43 |
| bauzas | how would you be able to provide solutions for the tests that would have problems ? | 16:44 |
| bauzas | do you know about the vmwareapi driver? | 16:44 |
| bauzas | running a job is possible, making it fiable is more difficult | 16:44 |
| grandchild | if you ask about our familiarity with the vmware driver code, i'd say it's fairly hih | 16:44 |
| fwiesel | gibi: It is hard for us yet to give a timeline on the CI as we are yet unclear about how much effort it will be for us. | 16:44 |
| bauzas | s/fiable/reliable | 16:44 |
| gibi | fwiesel: I see | 16:45 |
| fwiesel | We maintain a fork here: https://github.com/sapcc/nova | 16:45 |
| fwiesel | Mostly because we try to work around issues of scalability in vmware which are probably not of interest to the general community. | 16:46 |
| bauzas | fwiesel: maybe if you could tell us how long you would need to find the needed efforts, this would be nice | 16:46 |
| bauzas | have you already run tempest against your fork ? | 16:46 |
| fwiesel | bauzas: Yes, we run tempest and unit tests. We have disable some tempest tests, I can check which ones. | 16:47 |
| sean-k-mooney | fwiesel: what do run them with is it devstack? | 16:48 |
| fwiesel | fwiesel: On the effort estimate, I can come back to you in a week. | 16:48 |
| bauzas | fwiesel: that's good to hear, that's a first thing | 16:48 |
| grandchild | we have a dedicated qa environment | 16:48 |
| fwiesel | sean-k-mooney: We run it in qa environments on k8s | 16:49 |
| sean-k-mooney | fwiesel: the tird party ci would have to deploy the gerrit chagne under review and report back with tempest test using the vmware driver | 16:49 |
| sean-k-mooney | you would not need to use devstack you could use your k8s install tool provided it uses the nova commit form the review | 16:49 |
| bauzas | fwiesel: do you already have ideas on how many runs you need to do for nova if you add a 3rd party CI ? | 16:49 |
| bauzas | fwiesel: because this can be large | 16:49 |
| sean-k-mooney | bauzas: its much less then it used ot be but yes its non trivial | 16:50 |
| bauzas | https://zuul.openstack.org/builds?project=openstack%2Fnova&branch=master&pipeline=check&skip=0 | 16:50 |
| fwiesel | sean-k-mooney: The main concern is here more that we have to run arbitrary code, so we want it a bit more isolated. | 16:50 |
| sean-k-mooney | fwiesel: yep form past expeince runing a third party ci for nova/neutron | 16:51 |
| sean-k-mooney | geting it approval to run it is non trivial | 16:51 |
| bauzas | fwiesel: grandchild: you can see in the above link how many builds we run | 16:51 |
| bauzas | for the 'check' pipeline | 16:51 |
| bauzas | and we can't unfortunately only test changes that modify the virt driver | 16:52 |
| grandchild | (zuul link throws 500 in fetching the jobs ;) ) | 16:52 |
| bauzas | because we could regress on vmwareapi by a change not related to the driver | 16:53 |
| grandchild | but i'd wager, like fwiesel said, isolation is more of an issue than load. | 16:53 |
| grandchild | bauzas: sure, we'd run the whole pipeline, we are aware of that | 16:53 |
| bauzas | for example, say someone modifies the virt API and forgets to modify vmwareapi module | 16:53 |
| bauzas | grandchild: cool, I just wanted to be aware | 16:54 |
| sean-k-mooney | grandchild: well you dont need to run the full pipeline | 16:54 |
| sean-k-mooney | you only need 1 job that runs on all changes to a subet of direcotries | 16:54 |
| sean-k-mooney | ideally any change the touches the compute and virt modules | 16:54 |
| bauzas | sean-k-mooney: that's my point | 16:54 |
| sean-k-mooney | and ideally som others | 16:54 |
| grandchild | sean-k-mooney: sorry if the terminology is off -- i meant the check for the whole codebase | 16:54 |
| bauzas | sean-k-mooney: I don't really know which modules they should only check | 16:55 |
| bauzas | but we could try to run something small first | 16:55 |
| sean-k-mooney | well ideally every change but at least every chagne to the compute and virt modules | 16:55 |
| bauzas | without removing the experimental tag | 16:55 |
| bauzas | and see how this goes first | 16:56 |
| bauzas | before adding more checks to the 3rd party pipeline | 16:56 |
| sean-k-mooney | sof feature freeze is feb 29th | 16:56 |
| sean-k-mooney | i had wanted the removals to happen before m1 | 16:56 |
| sean-k-mooney | i could be convinced to wait till around m2 for ci or very early febuary | 16:57 |
| grandchild | that sounds fair actually, 3 months to get something on its feet. might be achievable. | 16:57 |
| bauzas | here is what I can propose | 16:57 |
| grandchild | but like fwiesel said, a week for an estimate from us. | 16:57 |
| gibi | (if we remove the the driver from master the driver is be on the stable branches) | 16:57 |
| fwiesel | We could also turn it the other way around. You remove it, and we re-add it, when you are convinced it is fine. | 16:57 |
| bauzas | grandchild: fwiesel: would you be able to attend our meeting on a weekly basis ? | 16:57 |
| grandchild | bauzas: definitely | 16:57 |
| bauzas | okay, here is my proposal then | 16:58 |
| fwiesel | fwiesel: Yes | 16:58 |
| fwiesel | bauzas: Yes | 16:58 |
| bauzas | we could defer the removal until caracal-2 | 16:58 |
| bauzas | and every week, I'd add a topic in our meeting about your 3rd party CI | 16:58 |
| bauzas | you could then tell us where you are and what you need | 16:59 |
| bauzas | and if before end of December, we can't really see anything coming, then we would remove the virt driver | 16:59 |
| fwiesel | Fair enough. | 17:00 |
| grandchild | that sounds fine to me, fwiesel? | 17:00 |
| grandchild | k | 17:00 |
| bauzas | any other opinions but me ? | 17:00 |
| gibi | sound OK to me too | 17:00 |
| bauzas | I'm just a code herder, I'm not a L | 17:00 |
| sean-k-mooney | i can defer writing the remaining patches until after milestone 2 | 17:00 |
| sean-k-mooney | i have the patch to remove the driver already done | 17:00 |
| sean-k-mooney | but i can wait for the api/object changes until we see if the ci turns up by milestone 2 | 17:01 |
| bauzas | okay, then I can write the action item | 17:01 |
| bauzas | sean-k-mooney: I haven't checked, but surely the main patch isn't merged yet, right ? | 17:01 |
| sean-k-mooney | ill -w the removal patch for now | 17:01 |
| sean-k-mooney | its not but i wanted it to be | 17:01 |
| bauzas | okay, sounds a plan | 17:01 |
| sean-k-mooney | i was goign to ask for review today | 17:01 |
| bauzas | and we'll see on a weekly basis how this goes | 17:02 |
| bauzas | lemme write the action | 17:02 |
| bauzas | #agreed we defer the vmwareapi driver removal until caracal-2 | 17:02 |
| bauzas | #agreed fwiesel and/or grandchild will report on a weekly basis about their efforts on running a 3rd party CI for vmwareapi | 17:03 |
| bauzas | #action bauzas to create a meeting topic in order to discuss the efforts | 17:03 |
| grandchild | ftr: jkulik is not in the office today, but also in the mix from us :) | 17:03 |
| bauzas | sure | 17:04 |
| bauzas | sean-k-mooney: I appreciate your understanding about the deferral | 17:04 |
| sean-k-mooney | its ok ill ask ye to review other patches instead :P | 17:04 |
| grandchild | sean-k-mooney: we do too! thanks :) | 17:04 |
| bauzas | grandchild: fwiesel: I aslo appreciate your efforts in trying to bond with us | 17:04 |
| bauzas | let it be going | 17:04 |
| bauzas | and we'll see during the next weeks how things go | 17:05 |
| bauzas | we're waaaay overlate | 17:05 |
| sean-k-mooney | before we finish the meeting | 17:05 |
| sean-k-mooney | i did have a topic for this week | 17:05 |
| bauzas | shoot, but quick | 17:05 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/899381 | 17:05 |
| sean-k-mooney | basically does that need a specless blueprint or bug | 17:05 |
| sean-k-mooney | tl;dr libvirt can now tell use how many sev instnace we can create | 17:06 |
| sean-k-mooney | we have a optional config option to do that | 17:06 |
| sean-k-mooney | this patch will just auto detect the amount and report it | 17:06 |
| sean-k-mooney | it was deferd form the orgianl spec because we need libvirt to be modifed to enable this | 17:06 |
| bauzas | I'm fine with approving it as specless but telling them to create a spec if during the implementation reviews we find some design concerns | 17:06 |
| sean-k-mooney | well its actully more or less ready to merge | 17:07 |
| sean-k-mooney | i have one nit and wanted to answer this question before +2ing it | 17:07 |
| bauzas | given the change is already there, it's fine to review it now and ask for a spec if really needed | 17:07 |
| sean-k-mooney | and stephenfin previously +2'd it | 17:07 |
| bauzas | they wouldn't be impacted by the spec freeze | 17:07 |
| bauzas | which is later | 17:07 |
| bauzas | any controversial opinions on it being specless ? | 17:07 |
| bauzas | looks not | 17:08 |
| bauzas | we'll need tkajinam to create a blueprint | 17:08 |
| sean-k-mooney | ok lets ask tkajinam to file a specless blueprint for this then and review it as normal once done | 17:08 |
| sean-k-mooney | ya | 17:08 |
| sean-k-mooney | ok that was it | 17:08 |
| gibi | look OK to me | 17:08 |
| bauzas | #agreed https://review.opendev.org/c/openstack/nova/+/899381 could be specless | 17:08 |
| bauzas | #action tkajinam to create a blueprint and report it to bauzas so that he can late-approve it given above ^$ | 17:09 |
| bauzas | okay, we're definitely overlate | 17:09 |
| bauzas | really sorry about that | 17:09 |
| bauzas | thanks all | 17:09 |
| bauzas | #endmeeting | 17:09 |
| opendevmeet | Meeting ended Tue Nov 21 17:09:46 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.html | 17:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.txt | 17:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.log.html | 17:09 |
| elodilles | thanks o/ | 17:09 |
| bauzas | fwiesel: grandchild: I appreciate your efforts, ping me anytime | 17:10 |
| fwiesel | bauzas: thanks for the offer | 17:10 |
| elodilles | sean-k-mooney: here is the patch about the nova-emulation job removal: https://review.opendev.org/c/openstack/nova/+/901604 | 17:10 |
| sean-k-mooney | elodilles: i had one locally too but happy to go with yours | 17:10 |
| elodilles | sean-k-mooney: thx :) | 17:11 |
| sean-k-mooney | i was goign to move it to experimental but im fine to jsut drop it | 17:11 |
| bauzas | gibi: I don't want to be pedantic but I don't want https://review.opendev.org/c/openstack/nova/+/901188 to be a bugfix | 17:11 |
| sean-k-mooney | if someone wants to try and fix it they can just add it back in there patch | 17:11 |
| elodilles | sean-k-mooney: it still remains in the periodic-weekly pipeline at least | 17:12 |
| sean-k-mooney | since peoepls are not reviwign the vmware removal patch can we try and land teh codespell seriese sooner rather then later https://review.opendev.org/c/openstack/nova/+/897092/1 | 17:15 |
| gibi | bauzas: I still consider that as a UX bug. | 17:21 |
| bauzas | gibi: we wrote in the spec, I quote : | 17:21 |
| bauzas | "This is the operator’s responsibility to verify that the OS kernel is recent enough to support CPU core tuning and that those CPU cores have their governors supporting both the performance and the powersave profiles." | 17:22 |
| bauzas | if we magically make the feature opt-out, then we leave operators responsible of ensuring that their kernel can support cpu offline | 17:22 |
| gibi | I don't see how that implies that the feature cannot be enabled with zero PCPUs and expect to do nothing | 17:23 |
| gibi | bauzas: I'm not changing the default of the flag. It is still opt in | 17:23 |
| gibi | the operator needs to explicitly enable the feature | 17:23 |
| gibi | with [libvirt]cpu_power_management | 17:23 |
| gibi | with [libvirt]cpu_power_management = True | 17:24 |
| bauzas | touché | 17:25 |
| gibi | what changes is that the operator can enable [libvirt]cpu_power_management = True before decides about the PCPU list of the given host | 17:25 |
| bauzas | I mixed different conversations, one being not public | 17:26 |
| gibi | this allows to enable [libvirt]cpu_power_management globally in a cloud in a deployment engine, and set PCPU config on the hypervisor independetly later | 17:26 |
| bauzas | gibi: given the latter requires a nova-compute restart, I don't really see the benefits of enabling the former before, except if you have a deployment tool and you don't want your users to change that option | 17:27 |
| sean-k-mooney | bauzas: are there specific risks or concerns you have with this change? | 17:27 |
| sean-k-mooney | bauzas: i would eventully like to make [libvirt]cpu_power_management = True the default in nova by the way | 17:28 |
| bauzas | sean-k-mooney: none for the master patch itself | 17:28 |
| gibi | bauzas: there will be a single restart but there will be indedpendent decisions i) I need power management ii) I have a list of PCPUs used in a given hypervisor | 17:28 |
| bauzas | hence my +1 | 17:28 |
| sean-k-mooney | but i dont want to require cpu_dedicated_set | 17:28 |
| sean-k-mooney | ok so your concern is really just with framing this as a bug | 17:28 |
| gibi | and if the decision #ii) result in an empty cpu_dedicated_set then I don't want to go back to decision i) as that is still valid | 17:29 |
| bauzas | well, power management on non-dedicated cores is currently not something existing | 17:29 |
| sean-k-mooney | right but this has nothign to do with that | 17:29 |
| bauzas | sean-k-mooney: this is correct, as I wrote in both gerrit and here | 17:29 |
| gibi | true, but power management on zero PCPUs actually work | 17:29 |
| gibi | and help keeping the two configuration decision independent | 17:29 |
| bauzas | if we were enabling power management on shared cores, surely we would make those options independent | 17:30 |
| gibi | take my space heater example | 17:30 |
| gibi | the on/off button and the temp knob are independent decisions | 17:30 |
| sean-k-mooney | if we were to enabel it on shared cpus we woudl have to only supprot the governer policy | 17:30 |
| sean-k-mooney | we coudl not supprot the cpu state policy | 17:30 |
| sean-k-mooney | but even then i would expect new config optiosn for the cpu share set | 17:31 |
| gibi | I don't want to alway use the on/off button when my room becomes cold. I want to rely on the combination of the two config to dyanmically heat my room | 17:31 |
| sean-k-mooney | im not sure we will add that funcitonaltiy | 17:31 |
| sean-k-mooney | at least right now i dont see a uescase to do that | 17:31 |
| bauzas | you know what ? I'll stop | 17:32 |
| gibi | I stop too. See you tomorrow | 17:34 |
| bauzas | I sent it to... wait, actually nothing | 17:35 |
| bauzas | the check pipeline failed | 17:35 |
| bauzas | but I added a label called 'Workflow +1' | 17:35 |
| bauzas | fwiw | 17:35 |
| gibi | bauzas: thanks | 17:36 |
| bauzas | (fwiw, the analogy with a room heater seems wrong to me : the on/off button seems to me the opt-in flag about power management, and the temp knob is the strategy) | 17:40 |
| bauzas | and when I wrote the feature, I thought it was errorprone to tell "I want my cores to be power managed" if I wasn't providing dedicated cores | 17:41 |
| bauzas | but I don't want to debate for so long about that, so let's ship it | 17:42 |
| sean-k-mooney | the temp knob is hte cpu_dedicated_set (the quantiy of cpus) but i get your perspective too | 17:42 |
| bauzas | if some deployment tool automatically enables the power management feature, it still needs to properly document the fact that the strategy can be modifed | 17:44 |
| bauzas | maybe some operators would be surprised to see their cores offlined | 17:44 |
| bauzas | (at least I would) | 17:44 |
| sean-k-mooney | well that kind of raise the question of what the defautl behavior shoudl be upstream | 17:45 |
| bauzas | and maybe it wouldn't hit me that it was nova which offlined them for my usage | 17:45 |
| sean-k-mooney | i think we eventually woudl want to make that the default | 17:45 |
| sean-k-mooney | perhasp even this cycle although that should be a seperate patch | 17:45 |
| bauzas | sean-k-mooney: the problem here is that I don't want us to buy a feature that depends on a kernel support | 17:46 |
| sean-k-mooney | this has been supported in the kernel for a very very long time, although you ar ecorrect that it can be compiled out | 17:46 |
| bauzas | I don't know for exotic archs and kernels, but I don't wanna bet that all of them have the sysfs calls | 17:46 |
| sean-k-mooney | or disabeld such as when in a vm | 17:46 |
| sean-k-mooney | so you dont think we shoudl enabel by default in the long term then? | 17:47 |
| sean-k-mooney | its certnely not somethign we have to rush into | 17:47 |
| bauzas | I have some concerns about it and I need to be convinced that nova wouldn't stop supporting exotic kernels just because of that | 17:47 |
| sean-k-mooney | kind of like being secure by default i feel we shoudl try to be energy effiect by default | 17:48 |
| bauzas | sure, and that makes sense | 17:48 |
| sean-k-mooney | bauzas: well you could alwasy trun it off or we coudl try and detect it | 17:48 |
| bauzas | we should even | 17:48 |
| sean-k-mooney | prehasp we woudl intoduce an auto value in the future | 17:48 |
| bauzas | detecting whether you can disable them or not at startup | 17:49 |
| sean-k-mooney | ya | 17:49 |
| bauzas | yeah, this sounds a right way | 17:49 |
| bauzas | the auto thing | 17:49 |
| sean-k-mooney | so if mede it a tri state true,false,auto | 17:49 |
| sean-k-mooney | and then did the detection | 17:49 |
| sean-k-mooney | that would be the best of both worlds | 17:49 |
| sean-k-mooney | and it solves the ux problem but i also agree that would not be backportable | 17:50 |
| bauzas | yeah, and this would convince me of opting-out this | 17:50 |
| bauzas | provided the autodetect | 17:50 |
| sean-k-mooney | do we ant to wait to disucss this with gibi tomorrow before proceeding with the current patch | 17:51 |
| bauzas | this is additive | 17:54 |
| bauzas | and as you said, not backportable | 17:54 |
| opendevreview | Andriy Kurilin proposed openstack/python-novaclient master: Disable NEUTRON_ENFORCE_SCOPE at function job https://review.opendev.org/c/openstack/python-novaclient/+/901621 | 19:37 |
| opendevreview | Elod Illes proposed openstack/nova stable/yoga: [stable-only] Remove nova-emulation from check pipeline of Yoga https://review.opendev.org/c/openstack/nova/+/901604 | 20:41 |
| elodilles | sean-k-mooney: i forgot about the [stable-only] tag /o\ so now i've moved the job to experimental pipeline as you originally wanted ^^^ | 20:44 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: Allow live migrate paused instance when post copy is enabled https://review.opendev.org/c/openstack/nova/+/444517 | 21:06 |
| artom | melwitt, since you looked at it previously and sean-k-mooney now has a +2, can I bother you for https://review.opendev.org/c/openstack/nova/+/883682? | 21:09 |
| andreykurilin | Hi folks! python-novaclient-functional job became broken after neutron-related change to devstack https://review.opendev.org/c/openstack/devstack/+/899306 . I have a fix to unblock novaclient’s CI - https://review.opendev.org/c/openstack/python-novaclient/+/901621 but IDK whether the issue should be addressed differently. The review is appreciated. | 21:11 |
| melwitt | artom: sure, will look | 21:16 |
| *** haleyb is now known as haleyb|out | 22:12 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!