16:00:21 #startmeeting nova 16:00:21 Meeting started Tue Jul 19 16:00:21 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:21 The meeting name has been set to 'nova' 16:00:25 hello everyone 16:00:33 #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 16:00:53 * bauzas is currently trampled by internal issues with vgpus but I'll chair this meeting 16:01:08 who's around ? 16:01:15 o/ 16:01:22 o/ 16:01:25 o/ 16:01:45 o/ 16:02:02 o/ 16:02:36 ok, we can start 16:02:57 #topic Bugs (stuck/critical) 16:03:05 #info No Critical bug 16:03:30 #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 10 new untriaged bugs (-1 since the last meeting) 16:03:41 Uggla: thanks for helping on this 16:03:45 any bug to point out ? 16:04:46 mmmm, crickets 16:04:55 #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement 16:05:06 #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster 16:05:11 #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster 16:05:20 #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement 16:05:37 sean-k-mooney: do you have some time for looking at bugs this week ? 16:07:55 mmm, I'll discuss with sean-k-mooney later to know if he can 16:08:02 if not, I'll be the owner for this week 16:08:17 #topic Gate status 16:08:25 #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:08:30 i can make it 16:08:35 i proably dont but i will 16:08:39 sean-k-mooney: thanks, very much 16:08:49 sean-k-mooney: again, this is not a priority 16:08:55 do it as you can 16:09:23 the number of open bugs is pretty low at this time, which is cool, kudos to the team 16:09:30 its fine ill keep an eye on them 16:09:33 s/open/new 16:09:40 #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status 16:09:46 a new check : 16:09:52 #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly&skip=0 Centos 9 Stream periodic job status 16:10:19 sean-k-mooney: didn't had time to see whether you proposed a tempest patch for removing c9s from check and gate ? 16:10:34 isn't there some way to see previous periodic runs too? 16:10:42 bauzas: yes i did 16:10:44 so we can see that it's passed N times in a row? 16:10:45 dansmith: yes 16:10:53 or has this only run once? 16:10:54 dansmith: i can see if i can get that 16:11:08 dansmith: https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&skip=0 16:11:11 sean-k-mooney: not important now, just wanted to make sure we don't need to build a thing 16:11:11 i think you can filter the build by pipeline and proejct 16:11:24 ya basically ^ 16:11:37 dansmith: as you see, for the moment, we're still testing c9s in check and gate due to a tempest template 16:11:39 yeah but that only shows one periodic run, is that because it has only run once yet? 16:11:44 dansmith: correct 16:11:47 gtotcha 16:12:03 we could also check experiment if we want 16:12:13 https://review.opendev.org/c/openstack/tempest/+/850242 16:12:16 ta 16:12:22 that is the tempest template update patch ^ 16:12:28 ack 16:12:46 #link https://review.opendev.org/c/openstack/tempest/+/850242 removing Centos 9 stream jobs from default Tempest template 16:13:10 #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs 16:13:18 #info Please look at the gate failures and file a bug report with the gate-failure tag. 16:13:25 #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures 16:13:30 that's it 16:13:32 moving on 16:13:40 #topic Release Planning 16:13:48 #link https://releases.openstack.org/zed/schedule.html 16:13:55 #info Zed-2 was last week 16:14:02 #info Specs are no longer accepted 16:14:23 #link https://blueprints.launchpad.net/nova/zed current blueprints open for the zed timeframe 16:14:41 13 bps 16:14:45 less than in Yoga 16:14:54 we could have one more 16:15:06 but this will be discussed in the open discussion 16:15:38 oh, I forgot to prepare an etherpad, stupid me 16:16:05 give me a second, I'd like to ask our API microversion proposers to ask for a specific microversion 16:16:19 instead of all of them rushing into 2.92 16:16:22 2.91 16:17:48 there it is 16:18:05 #link https://etherpad.opendev.org/p/nova-zed-microversions-plan Etherpad for a microversion use query 16:18:24 fwiw, I left 2.91 for https://review.opendev.org/c/openstack/nova/+/845897 16:18:40 and https://review.opendev.org/c/openstack/nova/+/849133 is now ready for 2.92 16:19:01 the latter will require a very small merge conflict resolution due to the api docs 16:19:24 but as you see, nothing was preventing me to use the 2.92 microversion even if 2.91 wasn't merged 16:19:46 that's why I propose our different change owners to ask for a microversion 16:20:34 you will have a bit more than a single conflict on the api doc but yes hopefully the conflict will be small 16:20:36 I'll send an email tomorrow explaining about this 16:20:42 gibi: I tested it 16:20:50 gibi: 4 files were conflicting 16:20:53 I expect a conflict on https://review.opendev.org/c/openstack/nova/+/849133/5/doc/api_samples/versions/v21-version-get-resp.json 16:21:04 yup, this one and the root v2 16:21:15 plus the rest api microversions list doc 16:21:21 and I can't remember the last one 16:21:23 and on the api_version_request.py 16:21:25 but easy conflicts 16:21:50 could be harder to resolve if two changes are touching the same API resource 16:22:01 but let's not overcomplicate this 16:22:01 fyi I have just reserved 2.93 for virtiofs 16:22:28 Uggla: then prepare your API change to use the 2.93 microversion, this should work like mine 16:22:31 bauzas: sure 16:23:44 tbc, we reserve the right to flip the microversions 16:23:50 need to review because I bet on 2.92. 16:23:53 depending on the state of the review 16:24:05 we had runways before 16:24:17 take it as a unformal runway for asking reviews 16:24:56 either way, I'll send an email explaining the rules 16:25:15 I don't want an overcomplicated process 16:25:29 this is just a way to prevent people doing frequent rebases 16:26:07 but the smaller microversion you ask, the higher you need to be reviewed hence be present 16:26:35 I just don't want us to wait for new revisions that could stale other changes 16:27:03 so I'll just say that we're free to drop some change from the microversion number 16:27:32 hope you folks don't disagree with this stupid plan 16:28:18 with the amount of folks pushing for a microversion right now I don't see trouble 16:28:30 sounds good 16:28:32 well, I see 5 different patches 16:28:34 at leasty 16:29:00 anyway, moving on 16:29:02 personally I would not bet on current+3 or higher to be ordered 16:29:18 #action bauzas to clarify the game rules of the etherpad in a later email tomorrow 16:29:19 but having a c+1 and c+2 ordered make sens 16:29:21 e 16:29:29 gibi: that's a reasonable point 16:29:36 I could remove 2.95 and newer 16:29:55 moving on 16:29:57 #topic Review priorities 16:29:57 and also if you are not ready for review then please don't allocate a microversion :) 16:30:07 gibi: that's the game rule 16:30:14 coolio 16:30:28 and if you are on vacations for 4 weeks, don't ask for the next microversion 16:30:49 or ask the next one, provided your patch can be reviewed before you leave 16:30:51 :) 16:30:56 :) 16:31:08 :) 16:31:28 * bauzas of course won't take 4 weeks off 16:31:33 only 3.5 16:31:51 #topic Review priorities 16:32:05 #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 16:32:16 huzzah 16:32:21 #link https://review.opendev.org/c/openstack/project-config/+/837595 is merged 16:32:51 #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for explains now the new gerrit flag and how to use it 16:33:21 would be interesting to see how many +1 will appeare on this list from now 16:33:53 I friggin hate the RP label btw 16:33:56 at least two from sean-k-mooney :) 16:34:11 bauzas: btw you need to update your query to show both +1 and +2 16:34:15 I keep RP+2ing patches and people ask a week later why I didn't CR+2 them :/ 16:34:30 dansmith: point them doc 16:34:31 they were proably form before the update 16:34:43 gibi: yeah I need to modify it 16:34:52 bauzas: no, I mean *I* do the wrong thing because I go looking for the +2 button to click and choose the wrong one 16:35:04 yes they were bot form before the cahnge merged 16:35:09 I wish RP could be a different scale like -A +B +C 16:35:11 but plese do look at them 16:35:21 dansmith: it can be 16:35:25 dansmith: valid point, can we change it from +2 to +B? 16:35:34 dansmith: ah I get your point 16:35:35 if we can choose anything, 16:35:38 it's confusing indeed 16:35:42 i am pretty sure it does not have to be a number 16:35:47 could we make it -NotYet, +Prio, +HighPrio ? 16:35:49 I don't know, we need to look at gerrit acls 16:36:06 or -Low, +Med, +High 16:36:06 i can check but this si just a cutom lable 16:36:24 don't do it just for me, but just relating my frustration with it on the glance side 16:36:24 dansmith: man, we got this https://review.opendev.org/c/openstack/project-config/+/837595 open for a while, you know your very good comment would have been more than appreciated then ? :D 16:36:46 anyway, it took us 6 months to get it 16:36:50 bauzas: sorry, but it has taken actual experience to realize it's annoying 16:37:02 I'm pretty sure we can take one month more to find if we can change the acls and to get it merged :p 16:37:08 bauzas: well thats just ebcause we didnt agree on what it shoudl be 16:37:13 if we can set a custom value 16:37:15 sean-k-mooney: not exactly 16:37:21 and we want too we can get it updated quickly 16:37:30 I will help push for reviews on a change if you want to do it 16:37:33 sean-k-mooney: it took us nearly a cycle to agree and then nearly a midcycle to get it merged 16:37:39 again, not trying to mess anything up, just conveying my experience 16:37:47 dansmith: your comment is legit 16:37:57 bauzas: thats just because i had asked them to wait until i went back to them 16:37:58 and I don't want contributors to mess this up 16:38:18 I would go for +P (contributor review promise) +CP (core review promise) 16:38:25 someone thinking he would +1 a patch and instead saying "yay, I'm committed on reviewing it soon" 16:38:30 is that what you meant by +1 +2? :) 16:38:34 if so, the labels would be much more useful 16:38:42 yup 16:38:51 https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_value 16:38:53 we'll figure it out 16:38:58 so it might need to be an int 16:39:39 the name can be anything we want 16:40:10 we can proably move on and confrim outside the meeting 16:40:14 ++ 16:40:23 ack 16:40:34 ++ 16:41:19 we have someone having added https://review.opendev.org/c/openstack/nova-specs/+/816542 to the agenda 16:41:44 Spec for modifiable user_data was accepted / merged, but implementations are still pending final review / merge 16:41:57 so I guess he's raising our attention to : 16:42:15 #link https://review.opendev.org/c/openstack/nova/+/816157 server implementation 16:42:19 #link https://review.opendev.org/c/openstack/python-novaclient/+/816158 novaclient 16:42:25 #link https://review.opendev.org/c/openstack/python-openstackclient/+/847792 openstackclient 16:42:28 yep i skimmed that 16:42:28 #link https://review.opendev.org/c/openstack/python-novaclient/+/816158 novaclient 16:42:40 this is one of the API changes we have 16:42:46 2.94 ? 16:43:14 im not sure if its reday to merge but its an api change yes 16:43:29 I'll add it to the etherpad 16:44:26 moving on 16:44:35 #topic Stable Branches 16:44:40 elodilles: are you around ? 16:44:42 yes 16:44:47 #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci 16:44:59 #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 so train is now 'more' broken 16:46:00 i could not reproduce the devstack issue locally yet 16:46:08 looks like the French SNCF rail 16:46:16 :) 16:47:18 anyway, i'll try to look into the issue, but any hint is appreciated 16:48:27 (i've added some details to the nova-stable-branch-ci, but haven't created a bug yet) 16:48:54 elodilles: honesly, I'm under the water as I speak 16:49:28 bauzas: ok, no problem, it's just a heads up for everyone who is interested in train branch :) 16:49:49 *some* may be interested 16:50:14 and that's it about stable branches from me i think 16:50:53 * gibi more and more feels we don't have the bandwidth to maintain stable/train 16:52:01 unfortunately, let's move on, then 16:52:15 #topic Open discussion 16:52:21 (sean) https://review.opendev.org/c/openstack/nova-specs/+/849488 spec freeze exception for spice compression 16:52:38 so yeah I wrote we could discuss this now 16:52:48 to see whether we punt it for Zed or we accept it 16:53:10 anyone having opinions about it ? 16:53:15 tbh, I'm meh to it 16:53:35 trying to honestly balance the risks vs. the benefits 16:53:54 risk shoudl be small since this is not user faceing 16:53:59 o/ 16:54:06 there is no api impact to this 16:54:17 this is configurable, right? 16:54:24 right 16:54:25 via host level config options only 16:54:30 and defaults to previous default 16:54:37 yeah, so basically a regression wouldn't be a big deal 16:54:47 we might want to default to unset 16:54:51 changing the options and that's it 16:54:53 but we could defer that to the implemation 16:54:56 yeah 16:54:59 to keep it entirly off by defualt 16:55:13 if that's purely additive and host-config based only, doesn't sound a big deal 16:55:23 i.e., "do not touch this part of libvirt's xml" by default? 16:55:30 correct 16:55:34 makes sense 16:55:34 no upgrade impact 16:55:38 right we cuurrently dont generate the elements 16:55:44 so we coudl continue to do that by default 16:55:51 agreed 16:55:58 I'm OK to grant the exception for this. 16:56:13 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 yoctozepto: do you have open changes against it ? 16:56:33 oh, that's bahnwaerter's question then 16:56:41 there is a nova change and nova-specs change open 16:56:50 ++ 16:56:52 so if we grant the excption we can update the sepc before we merge it 16:56:54 ok, so there is already a poc 16:57:01 yes 16:57:10 all the planets are aligned then 16:57:10 bauzas: Yeah, I was invited to this dicussion today ;) 16:57:27 let me take my baton then... 16:58:23 #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 cores, I'd appreciate if you could review it ASAP 16:58:54 (the spec, tbc) 16:59:18 that's it I guess for today 16:59:20 ill drop +2 given the pending change to the config behavior 16:59:28 not quite 16:59:37 sean-k-mooney: about the spec itself 16:59:47 (sean) there seams to be considerable outstanding question with regards to Configurable instance domains 16:59:50 oh ya so that it for that topic 17:00:07 yep so just want to make sure we disucssed ^ 17:00:09 https://review.opendev.org/c/openstack/nova-specs/+/850048 revert was merged 17:00:23 do we want to grant an exception for it ? 17:00:30 are we on to the domains thing? 17:00:33 yup 17:00:38 I do apologize pushing the spec through within such a sort timeframe last week 17:00:39 dns domain this 17:00:48 yeah I still (heartily) question the approach in general 17:00:48 https://review.opendev.org/c/openstack/nova-specs/+/850352 is the revert of the revert with some issues adressed 17:00:59 yes 17:01:04 fwiw, we're overtime 17:01:11 so we'll need to end the meeting 17:01:18 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 but I'd appreciate if people could continue the convo 17:01:38 bauzas: well we can extned 17:01:43 its in the nova changel now 17:01:46 but eitehr way 17:01:49 yeah 17:02:03 this is just we try to stick with one hour 17:02:05 anyway 17:02:14 dansmith: so do you think we shoudl take a step back and spend more time looking at this 17:02:24 personally I do, yeah 17:02:28 me too 17:02:38 I feel we require a proper brainstorming about it 17:02:39 then that fine we can defer to AA 17:02:41 I'd like to understand more of what we can and can't do with help from neutron 17:02:44 and not rush this 17:02:51 codifying this in our API is just a hack, IMHO 17:02:55 sounds good to me 17:03:21 yup, sounds we need a bit of a design time 17:03:25 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 so i think we shoudl spend some time between now and ptg evaulating this again 17:03:47 including the previous desision 17:03:48 sean-k-mooney: tbh, one week ago, we were still reviewing some metadata API change IIRC 17:04:12 bauzas: yes which we new would not work for quite a while 17:04:24 which, by reading the superseding spec, I understand why this approach is no longer possible 17:04:43 we can do the metadta change too 17:04:49 but it wont help the usecasue 17:04:58 its just providing more info to the domain 17:05:01 ... vm 17:05:06 which it will ignore 17:05:15 but yeah, sounds to me that domains are some information given by the network, not the user 17:05:17 * sean-k-mooney hates i typoed domain instead of vm 17:05:33 bauzas: i would disagree with that 17:05:40 but it really depend on the config 17:05:57 in generally the domain is carried by the port/floating ip and a default domain can be added to the netowrk 17:06:05 anyway we are over time 17:06:09 I think bauzas meant the network infra, 17:06:13 which is what I meant when I said it 17:06:20 well, unless I'm wrong, DNS is L5 17:06:26 right 17:06:29 not necessarily "the network object in neutron, distinct from the port object" 17:06:41 what is greate is this is not integrated with routed network properly either 17:06:48 yeah, not the "neutron network" 17:06:52 and I totally think it does come from network infra, at least in terms of plumbing 17:07:04 I meant 'the network infrastructure" 17:07:06 dansmith: its ment to be self service 17:07:07 if you override it in your guest OS, that's fine, but we don't need to be involved in that level, IMHO 17:07:17 at least with designate the model is bring your own domain 17:07:42 this is some data Nova doesn't have to deal with 17:07:43 sean-k-mooney: totally, but we should integrate with the services providing the network infra, even if you took your own domain to them 17:07:47 you point your domain mx rcords to desigante and then manage it as an enduser independet of the cloud admin 17:07:54 yep, understand 17:08:16 I'm not saying openstack shouldn't handle this, I'm saying I think nova is probably not the right place to set this per-instance 17:08:17 in theory, you could even have your DNS servers totally uncorrelated from OpenStack services 17:08:34 yes. 17:08:39 but Nova shouldn't be managing it 17:08:52 anyway im not going to ask for a spec freeze excption for this 17:08:58 this could be some "metadata" information 17:09:10 yeah and we need to end the meeting 17:09:15 im not sure i agree with "nova shoudl not be managing this" but i understand why you have that view point 17:09:24 so yes lets end the meeting 17:09:55 let's end the meeting for now 17:09:57 and we'll continue 17:10:00 thanks all 17:10:03 #endmeeting