| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 16:44:42 | elodilles | yes | |
| 16:44:47 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:44:59 | elodilles | #info stable/train is blocked, fix exists but hasn't merged yet due to intermittent failures + now nova-grenade-multinode & nova-live-migration started to fail @ devstack 'create' phase | |
| 16:45:24 | elodilles | so train is now 'more' broken | |
| 16:46:00 | elodilles | i could not reproduce the devstack issue locally yet | |
| 16:46:08 | bauzas | looks like the French SNCF rail | |
| 16:46:16 | elodilles | :) | |
| 16:47:18 | elodilles | anyway, i'll try to look into the issue, but any hint is appreciated | |
| 16:48:27 | elodilles | (i've added some details to the nova-stable-branch-ci, but haven't created a bug yet) | |
| 16:48:54 | bauzas | elodilles: honesly, I'm under the water as I speak | |
| 16:49:28 | elodilles | bauzas: ok, no problem, it's just a heads up for everyone who is interested in train branch :) | |
| 16:49:49 | bauzas | *some* may be interested | |
| 16:50:14 | elodilles | and that's it about stable branches from me i think | |
| 16:52:01 | bauzas | unfortunately, let's move on, then | |
| 16:52:15 | bauzas | #topic Open discussion | |
| 16:52:21 | bauzas | (sean) https://review.opendev.org/c/openstack/nova-specs/+/849488 spec freeze exception for spice compression | |
| 16:52:38 | bauzas | so yeah I wrote we could discuss this now | |
| 16:52:48 | bauzas | to see whether we punt it for Zed or we accept it | |
| 16:53:10 | bauzas | anyone having opinions about it ? | |
| 16:53:15 | bauzas | tbh, I'm meh to it | |
| 16:53:35 | bauzas | trying to honestly balance the risks vs. the benefits | |
| 16:53:54 | sean-k-mooney | risk shoudl be small since this is not user faceing | |
| 16:53:59 | yoctozepto | o/ | |
| 16:54:06 | sean-k-mooney | there is no api impact to this | |
| 16:54:17 | bauzas | this is configurable, right? | |
| 16:54:24 | yoctozepto | right | |
| 16:54:25 | sean-k-mooney | via host level config options only | |
| 16:54:30 | yoctozepto | and defaults to previous default | |
| 16:54:37 | bauzas | yeah, so basically a regression wouldn't be a big deal | |
| 16:54:47 | sean-k-mooney | we might want to default to unset | |
| 16:54:51 | bauzas | changing the options and that's it | |
| 16:54:53 | sean-k-mooney | but we could defer that to the implemation | |
| 16:54:56 | bauzas | yeah | |
| 16:54:59 | sean-k-mooney | to keep it entirly off by defualt | |
| 16:55:13 | bauzas | if that's purely additive and host-config based only, doesn't sound a big deal | |
| 16:55:23 | yoctozepto | i.e., "do not touch this part of libvirt's xml" by default? | |
| 16:55:30 | bauzas | correct | |
| 16:55:34 | yoctozepto | makes sense | |
| 16:55:34 | bauzas | no upgrade impact | |
| 16:55:38 | sean-k-mooney | right we cuurrently dont generate the elements | |
| 16:55:44 | sean-k-mooney | so we coudl continue to do that by default | |
| 16:55:51 | yoctozepto | agreed | |
| 16:55:58 | gibi | I'm OK to grant the exception for this. | |
| 16:56:13 | bahnwaerter | sean-k-mooney: Yeah, I could change that. It makes more sense to only set the libvirt entries if they are specified in a nova.conf | |
| 16:56:20 | bauzas | yoctozepto: do you have open changes against it ? | |
| 16:56:33 | bauzas | oh, that's bahnwaerter's question then | |
| 16:56:41 | sean-k-mooney | there is a nova change and nova-specs change open | |
| 16:56:50 | yoctozepto | ++ | |
| 16:56:52 | sean-k-mooney | so if we grant the excption we can update the sepc before we merge it | |
| 16:56:54 | bauzas | ok, so there is already a poc | |
| 16:57:01 | sean-k-mooney | yes | |
| 16:57:10 | bauzas | all the planets are aligned then | |
| 16:57:10 | bahnwaerter | bauzas: Yeah, I was invited to this dicussion today ;) | |
| 16:57:27 | bauzas | let me take my baton then... | |
| 16:58:23 | bauzas | #agreed https://review.opendev.org/c/openstack/nova-specs/+/849488/ granted as a spec deadline exception, sounds reasonable provided there is no upgrade impact and the change being purely self-contained and additive | |
| 16:58:38 | bauzas | cores, I'd appreciate if you could review it ASAP | |
| 16:58:54 | bauzas | (the spec, tbc) | |
| 16:59:18 | bauzas | that's it I guess for today | |
| 16:59:20 | sean-k-mooney | ill drop +2 given the pending change to the config behavior | |
| 16:59:28 | sean-k-mooney | not quite | |
| 16:59:37 | bauzas | sean-k-mooney: about the spec itself | |
| 16:59:47 | bauzas | (sean) there seams to be considerable outstanding question with regards to Configurable instance domains | |
| 16:59:50 | sean-k-mooney | oh ya so that it for that topic | |
| 17:00:07 | sean-k-mooney | yep so just want to make sure we disucssed ^ | |
| 17:00:09 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/850048 revert was merged | |
| 17:00:23 | bauzas | do we want to grant an exception for it ? | |
| 17:00:30 | dansmith | are we on to the domains thing? | |
| 17:00:33 | bauzas | yup | |
| 17:00:38 | gibi | I do apologize pushing the spec through within such a sort timeframe last week | |
| 17:00:39 | bauzas | dns domain this | |
| 17:00:48 | dansmith | yeah I still (heartily) question the approach in general | |
| 17:00:48 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/850352 is the revert of the revert with some issues adressed | |
| 17:00:59 | sean-k-mooney | yes | |
| 17:01:04 | bauzas | fwiw, we're overtime | |
| 17:01:11 | bauzas | so we'll need to end the meeting | |
| 17:01:18 | dansmith | I know it will/would be more work to do this via integration with neutron, but it seems like it would be a lot better to do so | |
| 17:01:25 | bauzas | but I'd appreciate if people could continue the convo | |
| 17:01:38 | sean-k-mooney | bauzas: well we can extned | |
| 17:01:43 | sean-k-mooney | its in the nova changel now | |
| 17:01:46 | sean-k-mooney | but eitehr way | |
| 17:01:49 | bauzas | yeah | |
| 17:02:03 | bauzas | this is just we try to stick with one hour | |
| 17:02:05 | bauzas | anyway | |
| 17:02:14 | sean-k-mooney | dansmith: so do you think we shoudl take a step back and spend more time looking at this | |
| 17:02:24 | dansmith | personally I do, yeah | |
| 17:02:28 | bauzas | me too | |
| 17:02:38 | bauzas | I feel we require a proper brainstorming about it | |
| 17:02:39 | sean-k-mooney | then that fine we can defer to AA | |
| 17:02:41 | dansmith | I'd like to understand more of what we can and can't do with help from neutron | |
| 17:02:44 | sean-k-mooney | and not rush this | |
| 17:02:51 | dansmith | codifying this in our API is just a hack, IMHO | |
| 17:02:55 | dansmith | sounds good to me | |
| 17:03:21 | bauzas | yup, sounds we need a bit of a design time | |
| 17:03:25 | sean-k-mooney | im partly worried that we made dission in this space in the past that tie our hand but we may want to revaulate those | |
| 17:03:41 | sean-k-mooney | so i think we shoudl spend some time between now and ptg evaulating this again | |
| 17:03:47 | sean-k-mooney | including the previous desision | |
| 17:03:48 | bauzas | sean-k-mooney: tbh, one week ago, we were still reviewing some metadata API change IIRC | |
| 17:04:12 | sean-k-mooney | bauzas: yes which we new would not work for quite a while | |
| 17:04:24 | bauzas | which, by reading the superseding spec, I understand why this approach is no longer possible | |
| 17:04:43 | sean-k-mooney | we can do the metadta change too | |