21:00:39 <mriedem> #startmeeting nova 21:00:40 <openstack> Meeting started Thu Nov 10 21:00:39 2016 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:43 <openstack> The meeting name has been set to 'nova' 21:01:03 <takashin> o/ 21:01:08 <dansmith> o/ 21:01:10 <bauzas> \o 21:01:13 <hshiina> o/ 21:01:14 <melwitt> o/ 21:01:18 <edleafe> \o 21:01:42 * Vek waves 21:02:02 <tonyb> \o 21:02:11 <mriedem> alright lets get started 21:02:14 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 21:02:22 * mriedem cues up ho down music 21:02:32 <mriedem> #topic Release News 21:02:43 <mriedem> #link Ocata release schedule: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule 21:02:50 <mriedem> #info Next upcoming date: Nov 17: o-1 milestone, spec approval freeze 21:02:57 <mriedem> so that's a week from today 21:03:07 <mriedem> bauzas brought up the idea of a spec review sprint, 21:03:16 <mriedem> which i'm cool with, but what day would work for people? 21:03:32 <diana_clarke> o/ 21:03:34 <mriedem> knowing that there is going to be some lag in replies 21:03:36 <bauzas> tomorrow's bank holiday in some countries, which I stupidely forgot 21:03:46 <mriedem> ok so all non-US countries have tomorrow off 21:03:47 <mriedem> i'm told 21:04:03 <mriedem> so monday is probably the day if we do one 21:04:09 <bauzas> Monday would be the only possible day, yeah 21:04:21 <mriedem> i sort of feel we need a list of things that we want to see get in as semi priorities, and make a list to focus on 21:04:30 <bauzas> I agree 21:04:38 <mriedem> i've already starred more than i can probably review myself in a single dya 21:04:39 <mriedem> *day 21:04:57 <mriedem> so...what i propose is i make up a list of specs to review, mainly around things we talked about at the summit 21:05:02 <mriedem> and then we chug through that on monday 21:05:19 <mriedem> sound fair? 21:05:28 <bauzas> those owners should know about that, so they could update directly during the day 21:05:29 <mriedem> i mean, i realize it's not 100% for all, but 21:05:36 <mriedem> bauzas: well i'd make the list, send to the ML 21:06:00 <bauzas> mriedem: then it's cool, it's up to the owners to be responsive 21:06:10 <bauzas> and keep the ball running 21:06:17 <mriedem> yeah, of course anything close we think is good to get in that doesn't make the 17th will probably get an exception 21:06:59 <mriedem> #action mriedem to cull a list of priority specs to review for a spec review sprint on monday 11/14 and send that info to the ML 21:06:59 <bauzas> what I like with the idea of a sprint day means that we have owners and reviewers at the same page during one day 21:07:16 <bauzas> that's not just for reviewers 21:07:22 <mriedem> ok speaking of specs 21:07:23 <mriedem> #link Open specs: https://review.openstack.org/#/q/project:openstack/nova-specs+status:open 21:07:55 <mriedem> ok something not spec related 21:07:58 <mriedem> Poll: 2 or 3 days for the PTG? Wed-Thurs or Wed-Fri? The first two days will be cross-project. The last 3 days are meetup style. 21:08:14 <mriedem> i got an email from the foundation asking how many days we're going to have for the nova 'vertical' track at the PTG 21:08:20 <mriedem> that's really the meetup portion 21:08:22 <mriedem> i assume 3 21:08:25 <mriedem> but want to ask 21:08:42 <cdent> more the better I'd say 21:08:47 <edleafe> I was assuming all 3 21:08:52 <bauzas> we won't have a midcycle before 21:08:52 <dansmith> yep me too 21:08:58 <bauzas> so yeah, ++ for 3 21:09:13 <mriedem> #info nova will have 3 vertical days at the PTG 21:09:26 <edleafe> bauzas: yeah, this is a summit-like design session I guess 21:09:39 <mriedem> or...it's not 21:09:44 <mriedem> it's replacing the meetups 21:09:49 <bauzas> edleafe: I don't want to enter that discussion about what kind of format the PTG should be :) 21:09:54 <mriedem> the design summit at the summit is the 40 minute tracks 21:10:02 <mriedem> yeah, let's just say no one actually knows 21:10:05 <mriedem> so we'll figure out later 21:10:06 <edleafe> heh 21:10:19 <mriedem> ok moving on 21:10:19 <edleafe> well, in the sense that it is planning the next release 21:10:28 <edleafe> as opposed to mid-course corrections 21:10:35 <bauzas> edleafe: I just commented on the fact that the last f2f meeting before the PTG will be 4 months before 21:10:36 <tonyb> wheer later is "early March" ;P 21:10:54 <edleafe> tonyb: +1 21:11:01 <mriedem> let's move this to nova after the meeting 21:11:04 <mriedem> #topic bugs 21:11:12 <mriedem> no critical bugs 21:11:24 <mriedem> 60 new bugs to be triaged 21:11:37 <mriedem> that's down from 75 last friday, so thanks for those helping out there 21:11:55 <mriedem> gate status 21:11:58 <mriedem> things are pretty quiet 21:12:08 <mriedem> for now... 21:12:09 <mriedem> #info CI jobs are using Neutron now by default if they don't specify otherwise: https://review.openstack.org/#/c/392934/ - watch for fallout 21:12:16 <mriedem> ^ merged in the last hour 21:12:36 <mriedem> i'll be around for another hour or so, and then heading home but will be online tonight to help deal with any fallout if there is any 21:12:52 <mriedem> i don't have any news for 3rd party ci status 21:12:58 * tonyb will keep an eye out also 21:13:07 <mriedem> wznoinsk has a message in the ML about NFV minded third party CI jobs/tests to unite 21:13:28 <mriedem> questions / issues about bugs? 21:13:38 <mriedem> #topic reminders 21:13:41 <mriedem> #link Ocata review priorities https://etherpad.openstack.org/p/ocata-nova-priorities-tracking 21:13:57 <mriedem> #topic Stable branch status: https://etherpad.openstack.org/p/stable-tracker 21:14:09 <mriedem> we had a stable/newton release last week, 14.0.2 i think 21:14:24 <mriedem> lyarwood has been busy https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z 21:14:44 <mriedem> tonyb: liberty final releases next week or the week after? 21:15:02 <tonyb> mriedem: final release next week tagging eol the week after at this point 21:15:21 <mriedem> #info liberty final releases are next week (11/14), then liberty-eol the week after that 21:15:39 <mriedem> #topic subteam highlights 21:15:44 <mriedem> Cells v2 (dansmith) 21:15:53 <dansmith> oh, hello 21:16:05 <dansmith> we've got the things we discussed at summit underway, 21:16:20 <dansmith> specifically the cells scheduler interaction and quotas work 21:16:21 <dansmith> things seem happy 21:16:28 <dansmith> testing changes are up and or going in to support those things 21:16:33 <dansmith> fin? 21:16:37 <mriedem> ya 21:16:47 <mriedem> danke 21:16:48 <mriedem> Scheduler (edleafe) 21:16:54 <edleafe> short meeting 21:16:54 <edleafe> discussed needs for API for getting resource providers 21:16:54 <edleafe> agreed to discuss in a hangout afterwards 21:16:54 <edleafe> bauzas to make specless BP for cleaning up request spec 21:16:54 <edleafe> the rest were small details 21:17:00 <edleafe> dat's it 21:17:01 <bauzas> edleafe: that's done 21:17:07 <bauzas> and approved 21:17:13 <edleafe> bauzas: cool - saw that earlier 21:17:38 <mriedem> edleafe: ok, is anyone talking about upgrade / CI plans for the placement API in ocata? specifically, making it required to upgrade to ocata 21:17:46 <mriedem> we're working on making cells v2 required to upgrade to ocata 21:17:53 <mriedem> and making it a default in CI in ocata jobs 21:17:57 <mriedem> we need similar for placement 21:18:05 <edleafe> mriedem: no, we haven't covered that yet 21:18:35 <mriedem> #help need to figure out the upgrade / CI plans for the placement service so it's required to deploy that when upgrading to ocata 21:18:37 <edleafe> all we planned for ocata is to have the scheduler get a streamlined list of hosts from placement 21:18:58 <bauzas> edleafe: that could be a prerequisite to enable the placement API for that 21:18:59 <edleafe> mriedem: we agreed at the summit that the placement db would remain optional 21:19:00 <mriedem> dansmith: didn't we identify a need for some better wording in the newton release notes about running placement in newton to populate the needed things 21:19:02 <mriedem> before ocata 21:19:12 <dansmith> mriedem: yes, like "by optional we meant required" 21:19:18 <mriedem> surprise! 21:19:37 <mriedem> edleafe: ok so can you take that to the subteam meeting and start hashing out what the plan is there? 21:19:46 <edleafe> mriedem: sure thing 21:19:49 <mriedem> thanks 21:20:00 <bauzas> well, if operators enable the placement API now, newton computes will still be able to send their resources 21:20:07 <bauzas> but let's discuss that off 21:20:08 <mriedem> bauzas: yes, and that's part of what we need 21:20:21 <mriedem> part of that work is going to be documentation 21:20:37 <mriedem> "oh i see you want to upgrade to ocata but aren't running placement yet, well, let me tell you something..." 21:20:39 <bauzas> (FWIW, I'm on board with having it required for ocata, the sooner being the better) 21:20:48 <mriedem> dansmith also had an idea for a 'ready-to-upgrade' nova-manage CLI 21:21:00 * dansmith nods approvingly 21:21:01 <mriedem> to be part of our process 21:21:05 <mriedem> as we have a lot of balls in the air 21:21:09 <mriedem> oh heavens 21:21:21 <mriedem> anyway, things to think about 21:21:25 <mriedem> let us move on 21:21:32 <mriedem> tdurakov left me some notes about the live migration meeting 21:21:36 <mriedem> Review priorities: https://review.openstack.org/#/c/389546/ https://review.openstack.org/#/c/379638/ https://review.openstack.org/#/c/389687/ 21:22:02 <mriedem> i've had some exposure on the first 2, need eyes on the last one 21:22:23 <mriedem> the other highlight was they started a poc for post-copy testing 21:22:44 <mriedem> api subteam, 21:22:50 <mriedem> johnthetubaguy: are you around? 21:23:01 <mriedem> that's at 7am for me now so i basically don't make it 21:23:32 <mriedem> the priorities for the api subteam right now are really about getting agreement on specs we identified at the summit 21:23:34 <bauzas> I was partially following 21:23:54 <mriedem> some of that info is in my summit recap on the api session 21:24:11 <bauzas> yeah, most of the discussion was about things discussed at summit 21:24:18 <mriedem> sriov/pci meeting - don't have any notes here 21:24:19 <bauzas> and follow-ups 21:24:26 <mriedem> lbeliveau_: was there an sriov/pci meeting? 21:24:44 <mriedem> moving on 21:24:48 <mriedem> Notification (gibi) 21:25:03 <mriedem> these are the highlights 21:25:04 <mriedem> The notification transformation work progressing well, there are 4 transformation patches ready for core review. 21:25:10 <mriedem> syjulian works on the implementation of the json-schema-for-versioned-notifications bp the first two patches are ready for core review 21:25:18 <mriedem> The ocata-nova-priorities-tracking etherpad is up to date with the patches ready for core review 21:25:21 <lbeliveau_> mriedem: missed it this week, but heard from moshele that it was quick 21:25:28 <mriedem> lbeliveau_: ok 21:25:35 <mriedem> Discussion is ongoing in the 3 bug reports opened by searchlight guys to decide what extra data is needed for searchlight in the notifications. https://bugs.launchpad.net/nova/+bugs?field.tag=searchlight There are performance concerns about the extra db query needed to provide some of the data (BDM). 21:25:51 <mriedem> wrt ^, 21:26:04 <mriedem> dims opened a bug against oslo.messaging to provide a way to tell if notifications are enabled, 21:26:11 <mriedem> so we can avoid building payloads if we don't need to 21:26:33 <mriedem> and on the BDMs one gibi and I talked about potentially making that configurable, like the option about sending notifications on task_state changes 21:26:52 <mriedem> at least in the cases that we don't have the BDMs in scope for the notification already and would have to get them from the DB 21:27:18 <mriedem> ok any questions about subteam stuff? 21:27:27 <mriedem> #topic stuck reviews 21:27:34 <mriedem> there wasn't anything in the agenda 21:27:43 <mriedem> #topic open discussion 21:27:56 <mriedem> Specless BP request (hshiina) 21:28:04 <mriedem> https://blueprints.launchpad.net/nova/+spec/inject-nmi-ironic - Introduce inject NMI interface in nova ironic driver 21:28:21 <mriedem> hshiina: jroll: want to speak to any of these? 21:28:47 <hshiina> they are listed in ironic priorities in ocata. 21:28:50 <mriedem> the ironic spec was approved in newton https://review.openstack.org/#/c/186700/ 21:29:10 <mriedem> so for nmi injection, the work isn't done in ironic correct? 21:29:32 <mriedem> i'm fine with approving the specless blueprint, but it's obviously blocked 21:29:34 <mriedem> so i'll mark it as such 21:29:53 <hshiina> ironic work is not done yet. 21:29:58 <mriedem> #action mriedem to approve https://blueprints.launchpad.net/nova/+spec/inject-nmi-ironic as a specless feature parity blueprint but it's blocked on the ironic changes 21:29:59 <hshiina> but, will be done. 21:30:05 <mriedem> come hell or high water 21:30:12 <mriedem> ok this one: 21:30:12 <mriedem> https://blueprints.launchpad.net/nova/+spec/soft-reboot-poweroff - Support soft reboot and poweroff in nova ironic driver 21:30:41 <mriedem> soft power off is the graceful shutdown thing right? 21:30:50 <hshiina> yes 21:30:52 <mriedem> where we wait a certain amount of time for the guest os to shutdown before killing it 21:30:53 <mriedem> ok 21:31:07 <mriedem> yeah i imagine people with baremetal machines care about that... 21:31:39 <mriedem> looks like the same ironic spec as the NMI change https://review.openstack.org/#/c/186700/ 21:31:43 <mriedem> is that correct? 21:31:49 <hshiina> yes 21:31:54 <tonyb> I think it's fine from the nova side, if the h/w can't do it then meh. 21:32:02 <hshiina> both changes were propesed in one spec. 21:32:07 <mriedem> ok, same story then 21:32:17 <tonyb> If auto promoting soft power off to hard power off a thing we do in other drivers? 21:32:21 <mriedem> #action mriedem to approve specless feature parity blueprint https://blueprints.launchpad.net/nova/+spec/soft-reboot-poweroff but it's blocked on the ironic changes 21:32:32 <wznoinsk> hshiina, would soft mean either reboot command from within operating system or pressing power button (ACPI) where hard is plug out? 21:32:35 <mriedem> auto-promoting? 21:32:35 * tonyb thought the client needed to make 2 calls ... 21:32:54 <mriedem> tonyb: i believe we try soft and if it fails we hard reboot 21:33:00 <mriedem> oh sorry shutdown... 21:33:06 <mriedem> i'd have to dig into that code 21:33:11 <tonyb> mriedem: I read the spec as client requests a soft power off and if that doesn't complete promotoe it to hard poweroff 21:33:13 <mriedem> i know it's configurable....which is less than ideal 21:33:42 <hshiina> ACPI is sent via ipmi. 21:33:52 <tonyb> I know it's a little tangental but it'd be great if we had a plan to be consistent there for all HV drivers ... 21:33:55 <mriedem> tonyb: would need to look at that flow in nova today 21:34:07 <mriedem> there are a few config options involved 21:34:09 <tonyb> mriedem: sign me up boss 21:34:24 <mriedem> #action tonyb to figure out wtf we do wrt graceful shutdown 21:34:36 <wznoinsk> hshiina, ok, thanks 21:34:42 <mriedem> ok that's it for the agenda 21:34:49 <jlvillal> o/ 21:34:50 <mriedem> opening it up for open discussion if anyone has anything 21:34:50 <wznoinsk> mriedem, I was actually hoping I could use your voice to encourage people to share their opinion in the ML/etherpad about nfv tests 21:34:50 <hshiina> thanks 21:35:03 <mriedem> wznoinsk: did you see me mention that already? 21:35:26 <wznoinsk> yes, my wrist did shiver when you mentioned my (smartwatch disease) 21:35:38 <mriedem> #help give wznoinsk feedback on collaborating on NFV CI testing 21:35:45 <wznoinsk> thanks 21:35:56 <mriedem> anything else? 21:36:27 <mriedem> if not, on a personal note, i want to say i acknowledge the angst in the ML and if people want to talk to me about things, please do so 21:36:44 * tonyb requesst stable reviews .... 21:36:54 <mriedem> tonyb: for nova or in general? 21:36:59 <tonyb> I think there are a few that need a seconc +2 21:37:04 <tonyb> mriedem: .... nova 21:37:12 <mriedem> #help need help with stable branch reviews 21:37:18 <mriedem> ok that's on me, i'll take a look 21:37:21 <mriedem> remind me if i don't 21:37:38 <tonyb> mriedem: You published a few so it 21:37:53 <tonyb> 'd be good for johnthetubaguy or dansmith to take a look 21:38:04 <mriedem> ok if nothing else we'll end the meeting, thanks everyone 21:38:10 <mriedem> #endmeeting