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