14:00:43 #startmeeting nova 14:00:44 Meeting started Thu Oct 19 14:00:43 2017 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:48 The meeting name has been set to 'nova' 14:00:55 hi 14:00:55 o/ 14:00:56 o/ 14:00:57 o/ 14:00:57 &/ 14:01:02 o/ 14:01:05 o/ 14:01:09 \o 14:01:12 o/ 14:01:42 ok let's get started 14:01:45 #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:01:45 _o 14:01:48 \o even 14:01:54 #topic release news 14:02:01 #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule 14:02:08 #info Oct 19: q-1 milestone, nova spec freeze (today) 14:02:13 …..\o 14:02:17 i know people are still going through some spec reviews 14:02:40 #info Blueprints: 63 targeted, 42 approved, 1 complete 14:02:51 questions about the release? 14:03:11 #topic bugs 14:03:20 nothing marked critical 14:03:25 #info 16 new untriaged bugs (up 5 from last week) 14:03:37 gate status appears to be ok 14:03:46 zuulv3 issues seem to be under control 14:03:58 3rd party ci, no news really 14:04:16 for CI there was one thing i wanted to mention, 14:04:25 the grenade live migration job has been broken since we switched over to queens, 14:04:39 because of some ceph setup stuff with singleconductor mode in the grenade jobs, 14:04:44 i thought it would be a relatively easy fix https://review.openstack.org/#/c/508271 14:04:56 it might still be, but i haven't had the time to poke at this ^ 14:05:04 so if someone wants to help me out it'd be appreciated 14:05:21 really all that's left is sourcing the localrc that grenade creates so the scripts can get to the devstack variables 14:05:52 the alternative is not running with ceph-backed ephemeral storage for the grenade live migration job, but that is a pity 14:06:11 right now we're just running block storage 14:06:24 just saw nfs was still commented out :( 14:06:36 #help mriedem is looking for someone to help poke at fixing the grenade live migration job https://review.openstack.org/#/c/508271/ 14:06:44 yeah, NFS 14:06:45 psh 14:06:53 moving on 14:07:03 #topic reminders 14:07:11 Forum topics have been reviewed and the summit schedule is available. Start working on Forum session discussion etherpads and presentations. https://wiki.openstack.org/wiki/Forum/Sydney2017 14:07:37 some of the forum sessions are under my name since i submitted them but i'll probably look to offload some of that to others... 14:08:02 anything to discuss about the forum 14:08:02 ? 14:08:21 do we know if jay’s going to be there? otherwise I can probably moderate the placement one if mriedem doesn’t want to. 14:08:27 he will not be there 14:08:44 I'll be there and present for placement 14:09:02 we had talked about doing a call next week or some point before the forum, 14:09:05 to cover some content with jay 14:09:11 will keep you in the look chris 14:09:14 *loop 14:09:16 thanks 14:09:17 oh sad for jay 14:09:44 I can help of course 14:09:57 #topic stable branch status 14:09:58 but let's leave cdent or dansmith for that :) 14:10:07 #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z 14:10:13 #link Etherpad for bugs tracked for Pike backports: https://etherpad.openstack.org/p/nova-pike-bug-fix-backports 14:10:26 there is one more pike thing i wanted to get merged before a release 14:10:39 dansmith: https://review.openstack.org/#/c/513198/ 14:10:49 mriedem: was literally just doing it 14:10:53 yay 14:11:02 there is other stuff in pike but it can wait for the 16.0.3 14:11:11 #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z 14:11:23 not much activity there right now as ocata is the middle child of the stable releases 14:11:29 and therefore gets the least amount of attention 14:11:46 mriedem: happy to do that. still also working on some more articles. 14:11:49 #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z 14:12:00 newton is flushed 14:12:01 #info Oct 18 : stable/newton branches get tagged EOL: https://review.openstack.org/#/c/512905/ 14:12:05 today is newton eol 14:12:09 ^ is the last release request 14:12:09 wow 14:12:21 time flies 14:12:33 #topic subteam highlights 14:12:41 dansmith: no cells meeting but want to mention anything? 14:13:07 not really, just that edleafe's set needs the most attention I think 14:13:15 the buildrequests patch of mine second to that, 14:13:19 I think it just needs one more 14:13:27 but otherwise I think we're in good shape 14:13:48 ok. i said i'd review alternate hosts this week, but stable and spec freeze so... 14:13:52 maybe tomorrow 14:14:10 edleafe: scheduler highlights? 14:14:15 We discussed the lull in the Nested RP series while Jay was on vacation, and whether or not it would be a good thing to have more than one person involved in major efforts like this. 14:14:19 The other patch series all seem to be moving ahead without issue. 14:14:21 We also discussed the possibility of a "recovery mode" for self-healing when the placement data gets severely out of sync with reality. 14:14:24 That's it. 14:14:59 along the lines, i thought the other night about writing something in nova-manage that could give a report of what placement says your allocations are and what we think they should be 14:15:05 to detect if we're leaking anywhere 14:15:10 but...just a thought 14:15:10 edleafe: have we seen the placement data get severely out of sync with reality? 14:15:30 jaypipes: no, but the use case was that the db gets whacked 14:15:36 or something similar 14:15:50 we said in the meeting if the db gets dropped it's not really on nova 14:16:10 i was more concerned with leaks because of the numerous bugs we've had about cleaning up allocations on failed moves 14:16:24 jaypipes: the reason I initially brought it up was in the case that the db got _deliberately_ wacked and state reset was required, using base reality (the compute nodes themselves). It was speculative talk. 14:16:40 jaypipes: we have seen it get out of sync when we have a bug and then need patching up, which I think is likely 14:16:47 oh yeah, which reminds me about a post-script for the ci jobs to dump allocations from placement to see if we're leaking anything, which depends on the osc plugin, which still needs review 14:17:12 jaypipes: I think we do need the ability to fix those holes somehow, but it's going to be pretty intense I think 14:17:28 cdent: and because the RT no longer auto-heals allocations right? 14:17:32 ^ is part of the reason 14:17:41 dansmith: well, that "use case" is around 85% of the code in the resource_tracker.py file currently ;) 14:17:47 I don't think the whole db getting killed is a good example, personally 14:17:51 dansmith: so it wouldn't be a new use case... 14:17:56 but sure, cool with me. 14:18:13 alright, moving on 14:18:28 alex_xu: api meeting highlights? 14:18:36 Talk about the spec https://review.openstack.org/#/c/508101/ - "Spec for API extensions policy removal", decided that the spec is only about deprecating the policy rule which have non-admin default rule. 14:18:42 that's it 14:19:19 so i haven't gone through that yet, but i assume it's for deprecating policy rules on things like BDMs in a server create request yeah? 14:19:36 like, we don't actually expect anyone ever to disable being able to do BDMs in a POST /servers request at this point 14:19:42 mriedem: for attributes in response. 14:20:00 ok 14:20:05 yea, for those extended server attributes 14:20:22 mainly when API add attributes in Show list detail server response 14:20:23 if i can't get my accessIPs in my server response, i'll be so mad 14:20:50 * mriedem still doesn't know what access IPs are used for 14:20:53 * bauzas needs to disappear for 20 mins 14:21:01 ok moving on 14:21:05 now that bauzas is gone... 14:21:14 gibi: notifications? 14:21:20 really short meeting 14:21:28 no real progress last week 14:21:35 and today bp service-create-destroy-notification 14:21:39 has been merged 14:22:02 no meeting next week as I will be on vacation on Monday Tuesday 14:22:06 that is all 14:22:22 gibi: speaking of that spec, https://review.openstack.org/#/c/444731/ - i don't know if the author still plans on working on it, you might want to reach out in case you're interested in picking it up 14:22:25 you might not be though 14:22:39 could be good for anyone new looking to work on something too 14:22:50 mriedem: I will try to catch the author 14:22:56 ok last thing, 14:22:58 cinder updates 14:23:11 ildikov needs to update the multiattach spec, 14:23:25 there was a patch split out of the refresh_connection_info changes https://review.openstack.org/#/c/512626/ 14:23:28 johnthetubaguy: ^ should be easy 14:23:36 would +2 but i added the test 14:23:45 mriedem: will have a peak at that topic again 14:23:54 stvnoyes updated the live migration patch, i ran CI again on that last night and it looks happy, just about to confirm and then will +2 14:24:04 otherwise we're waiting on cinder changes starting here: https://review.openstack.org/#/c/510201/ 14:24:25 #topic stuck reviews 14:24:29 nothing on the agenda 14:24:32 anyone have something to mention? 14:24:47 #topic open discussion 14:24:54 mriedem: we have a priority review list for specs last day today? 14:24:54 nothing on the agenda, so i'll open it up 14:25:01 jaypipes: no 14:25:16 jaypipes: check your email, i sent you the ones i've been watching 14:25:17 but that's it 14:25:31 mriedem: kk 14:25:40 * jaypipes checks 800+ unread emails 14:25:56 per usual, we're already over committed for the release so not everything is going to make it, and i don't expect spec freeze exceptions 14:26:22 ok anything else? 14:26:32 alright thanks everyone 14:26:34 #endmeeting