14:01:56 #startmeeting nova 14:01:57 Meeting started Thu Aug 8 14:01:56 2019 UTC and is due to finish in 60 minutes. The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:00 The meeting name has been set to 'nova' 14:02:20 o/ 14:02:22 o/ 14:02:31 * gmann in TC meeting also in parallel 14:02:35 o/ 14:02:45 o/ 14:03:41 o/ 14:05:11 #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:05:15 (updated just now) 14:05:33 #topic Last meeting 14:05:33 #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-08-01-21.00.html 14:06:08 actions from last time will come around again in open discussion 14:06:16 #topic Release News 14:06:24 We're in code mode now. 14:06:45 Feature freeze in ~5 weeks, Sep 12 14:07:12 #topic Bugs (stuck/critical) 14:07:12 No Critical bugs 14:07:12 #link 67 new untriaged bugs (-0 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 14:07:12 #link 1 untagged untriaged bugs (-1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW 14:07:20 any bug news? 14:08:07 #topic Gate status 14:08:07 #link check queue gate status http://status.openstack.org/elastic-recheck/index.html 14:08:07 #link 3rd party CI status (seems to be back in action) http://ciwatch.mmedvede.net/project?project=nova 14:08:43 we seem to be hitting 700-ish in-use nodes in the CI http://grafana.openstack.org/d/rZtIH5Imz/nodepool?orgId=1 14:08:48 which is a big bump 14:09:04 yet anecdotally, build times don't seem to have gone down a whole lot. 14:09:18 any comments there? 14:09:38 #topic Reminders 14:09:38 Anything? 14:09:56 #topic Stable branch status 14:09:56 #link stable/stein: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/stein 14:09:56 #link stable/rocky: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/rocky 14:09:56 #link stable/queens: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/queens 14:10:05 I think mriedem is gearing up for a rocky release 14:10:08 yes, 14:10:12 cve fixes https://review.opendev.org/#/q/I5e0a43ec59341c9ac62f89105ddf82c4a014df81 14:10:14 #help stables review rocky patches please 14:10:50 anything else stable mriedem? 14:10:53 no 14:11:00 #topic Sub/related team Highlights 14:11:00 Placement (cdent) 14:11:00 #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008192.html 14:11:07 oh hi 14:11:32 cdent has been diligently chipping away at performance 14:11:34 lots of performance updates that have proven quite useful. I'm going to write up a thing about the general classes of changes that were made so that we can try to transfer some of them over to nova 14:11:41 ++ 14:12:07 if I continue to have the time and space to do so, I'm just gonna carry on with the same analysis in nova-land 14:12:07 that it? 14:12:13 one thing that may be a concern: 14:12:58 tssurya: not sure if you are here, but I'll speak your name in vain. They are working on implementing consumer types in placement (which is of value to nova quotas) and progress is relatively slow (compared to other features in placement this cycle) 14:13:25 for the sake of nova we may want to see about helping out with that, depending on what tssurya has to say 14:13:33 (that's all) 14:14:00 who on the nova side is counting on consumer types? melwitt? 14:14:02 cdent: I wasn't aware it was a priority honestly 14:14:05 on the nova side 14:14:16 tssurya: I don't know if it is or not, which is why I bring it up 14:14:24 if it's not, then no big deal 14:14:37 if it is, then we can perhaps make some adjustments 14:14:50 i should probably read that spec, 14:14:54 the slow progress is truly my fault, apologies 14:15:09 since knowing the type of consumer for allocations could be useful for when we're deleting a compute service and hit conflicts, or the audit placement cli 14:15:20 tssurya: we've all got many things on the plate, don't worry 14:15:23 but none of those are priorities as far as i know 14:16:19 mriedem: you appear to have at least glanced at the spec on June 27th 14:16:21 at least of the people here, it sounds like no one is clamouring, but not everyone is here 14:17:14 Yeah, I can't quite tell from the 14:17:15 #link consumer types spec (review) https://review.opendev.org/#/c/654799/ 14:17:15 who/what the major motivators were 14:17:32 but melwitt was at least involved, so probably need to fup with her 14:17:41 cdent: your action ^ ? 14:17:56 sure, I'll check in 14:18:05 #action cdent to track down why we care about consumer types, and how motivated we should be to close it in Train 14:18:10 thanks 14:18:19 moving on 14:18:32 #topic Stuck Reviews 14:18:33 any? 14:19:09 #topic Review status page 14:19:10 #link http://status.openstack.org/reviews/#nova 14:19:10 Count: 459 (-2); Top score: 1373 (+21) 14:19:10 (FWIW, one week == 21 points) 14:19:10 #help Pick a patch near the top, shepherd it to closure 14:19:28 #topic Open discussion 14:19:28 Train Spec Freeze Exception Process 14:19:37 Last week we decided to dump all the decisions on dansmith 14:19:38 efried: you missed API :) 14:19:46 Ugh, sorry gmann 14:19:54 #topic Sub/related team Highlights 14:19:59 API (gmann) 14:19:59 This week updates: http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008358.html 14:19:59 gmann is working on 'Default policy refresh' and first API policies (os-services) series of changes is up for early feedback and direction. 14:19:59 This patch and all base patches: https://review.opendev.org/#/c/648480/7 14:20:01 #undo is a thing 14:20:18 mainly on thing about early feedback 14:20:24 regarding the last one "policy default refresh" initial series, i will catch melwitt and johnthetubaguy after meeting to discuss if this direction is good for them. and also will try to prepare an etherpad to write down the each changes motive to make it easy for review 14:20:47 i am looking for early feedback on this and its base patches https://review.opendev.org/#/c/648480/ 14:20:54 "review guide on ML" has been helpful for things. 14:21:05 and same line we can work on other policy also 14:21:13 * efried still has mriedem's cross-cell resize review guide in the queue.... 14:21:13 efried: sure. i can add that on ML 14:21:43 that's all on API. 14:21:56 thanks gmann 14:22:14 #topic Open discussion 14:22:14 Train Spec Freeze Exception Process 14:22:21 Last week we decided to dump all the decisions on dansmith 14:22:51 ...who has commented on both of the specs: 14:22:51 #link Use PCPU and VCPU in One Instance: https://review.opendev.org/#/c/668656/ 14:22:51 #link Nova Part of Image Encryption: https://review.opendev.org/#/c/608696 14:23:13 dansmith: are we saying definitively no at this point? 14:23:27 I never signed up to make the final call, 14:23:29 but tbh, 14:23:31 i say defer 14:23:31 Heh 14:23:37 no, we signed you up in absentia 14:23:40 if these aren't clear at this point in train, defer 14:23:40 it seems like there is little support for either being an exception 14:23:43 they aren't exception worthy 14:24:11 Okay. 14:24:27 being rushed for an exception makes one feel like they need to just approve to make people happy and keep the wheels grinding 14:24:57 I would like to be able to encourage the authors to continue working on the specs, in backlog-land, so they can land early in U. 14:25:06 yeah i think that's fine, 14:25:13 I haven't been deep in the technical details, but they seemed close to me. 14:25:15 knowing that to go from backlog -> U is still not a trivial re-approval 14:25:27 so, on that, 14:25:40 why don't we just propose them against U, and even potentially approve them at some point? 14:25:48 going into the backlog and then needing a re-review just seems pointless to me 14:26:01 if the U stuff is populated that's also fine 14:26:08 wfm. As soon as we have a name, I'll (ask someone to) populate the tree and we can do that. 14:26:11 backlog was historically more for an idea or problem w/o a solution 14:26:16 other than to serve as making it look like we've handed them half a bone, to make ourselves and them feel better 14:26:22 takashin has done it in the past 14:26:27 populating nova-specs with the next series 14:26:29 yuh 14:26:45 okay, moving on. 14:26:49 aciton? 14:26:52 *action even 14:27:11 #action takashin to populate nova-specs with U as soon as U has a name 14:27:25 okay 14:27:36 #action Luzi and huaqiang to move their respective specs to U 14:28:10 Thanks takashin 14:28:14 (mriedem): 14:28:14 #link python-novaclient blueprint to add --migration-type and --source-compute filters to "nova migration-list": https://blueprints.launchpad.net/python-novaclient/+spec/more-migration-list-filters 14:28:50 mriedem is requesting approval for specless blueprint ^ 14:28:59 what say you, all? 14:29:13 i've already got code up, just waiting to write tests, 14:29:21 this isn't dependent on microversion, it's legacy v2.0 stuff, 14:29:29 and it's novaclient, so not really a spec freeze exception kind of thing 14:29:41 heh 14:29:49 widening the gap with OSC, I see! 14:29:52 also, osc doesn't have any migration resource stuff 14:29:54 was about to say 14:29:58 i would have done osc 14:29:59 except ^ 14:30:05 :( 14:30:07 why not both? ;) 14:30:07 and when osc gains migration stuff, it would likely use this 14:30:09 so there 14:30:24 * mriedem checks how many knives he has available 14:30:40 i guess just the one will do 14:30:54 works for me 14:30:59 dude, don't stab me with a knife bloodied by someone else 14:31:04 if someone else from the nova team wants to help out with osc gaps i'll be happy to let you know what needs doing 14:31:05 think of the health risks 14:31:12 dansmith: sorry 14:31:52 * cdent must go, bbs 14:32:20 okay, I'll approve with notes after the meeting. 14:32:25 anything else? 14:32:50 Thanks all 14:32:50 o/ 14:32:50 #endmeeting