14:00:36 <mriedem> #startmeeting nova
14:00:37 <openstack> Meeting started Thu Apr 20 14:00:36 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:40 <openstack> The meeting name has been set to 'nova'
14:00:49 <efried> \*
14:00:52 <lyarwood> \o
14:00:54 <edleafe> \o
14:00:56 <jaypipes> yo.
14:01:01 <johnthetubaguy> o/
14:01:03 <cdent> \o/
14:01:04 <alex_xu> o/
14:01:24 <takashin> o/
14:01:38 <mriedem> alright let's get started
14:01:40 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:45 <mriedem> #topic release news
14:01:51 <mriedem> #link Pike release schedule: https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule
14:02:02 <dansmith> o/
14:02:02 <mriedem> #info Blueprints: 69 targeted, 63 approved, 3 completed
14:02:13 <jaypipes> no news is good news with gary gnu.
14:02:13 <mriedem> #link pike-1 recap and pike-2 focus: http://lists.openstack.org/pipermail/openstack-dev/2017-April/115700.html
14:02:32 <mriedem> questions about release things?
14:02:45 * bauzas waves a bit late
14:02:48 <mdbooth> o/
14:02:50 <johnthetubaguy> I like the checkpoint email, no real questions from me
14:02:59 <jaypipes> johnthetubaguy: ++
14:03:00 <efried> +1
14:03:06 <mriedem> #topic bugs
14:03:14 <mriedem> no critical bugs in LP
14:03:38 <mriedem> new untriaged numbers have gone down, thanks in large part to efried going through those last week
14:04:06 <mriedem> gate status is ok'ish
14:04:16 <mriedem> there have been some nova py35 unit test failures,
14:04:19 <mriedem> melwitt has a fix for one
14:04:30 <mriedem> https://review.openstack.org/#/c/458161/
14:04:35 <mriedem> someone should +W that
14:04:43 <dansmith> oh I was going to ask
14:04:45 <dansmith> I'll look
14:04:56 <mriedem> the other is some odd python stack dump / infinite recursion problem with oslo.confg
14:04:58 <mriedem> *config
14:05:04 <mriedem> i don't have a bug for that yet
14:05:14 <sfinucan> mriedem: example?
14:05:18 <mriedem> not handy
14:05:22 <sfinucan> (y)
14:05:30 <mriedem> check the irc nova logs from yesterday where i'm talking to gcb
14:05:38 * sfinucan will take a look at that later
14:06:16 <mriedem> third party ci doesn't have much news, except jaypipes (and others) would like to know who's running the intel nfv 3rd party ci now that wznoinsk is gone
14:06:24 <efried> Somewhere around here: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-19.log.html#t2017-04-19T14:44:18
14:06:54 <mriedem> i'll try to follow up with sean mooney about the intel ci
14:07:00 <sfinucan> mriedem: Last I heard, it was another Intel team in...Poland
14:07:14 <mriedem> ok
14:07:17 <jaypipes> sfinucan: no, it's the Irish team still I think.
14:07:25 <mriedem> i care less about ownership,
14:07:29 <mriedem> and more about what the status is
14:07:39 <jaypipes> sfinucan: sean was getting info on it for me.
14:07:44 <johnthetubaguy> good to have a contact when it breaks
14:07:48 <jaypipes> ya
14:07:52 <mriedem> yeah, true
14:07:59 <mriedem> final thing for bugs
14:08:05 * johnthetubaguy notes the lack of "if"
14:08:08 <mriedem> #link http://lists.openstack.org/pipermail/openstack-dev/2017-April/115704.html Launchpad bugs cleaning day on Tuesday 4/25
14:08:22 <mriedem> this is not the bug smash
14:08:28 <mriedem> this is going through old bugs in LP
14:08:30 <mriedem> and cleaning house
14:08:37 <mriedem> we did this almost exactly a year ago
14:08:56 <mriedem> so mark your calendars
14:08:58 <mriedem> for fun
14:09:02 <mriedem> i'll bring donuts
14:09:22 <mriedem> #topic reminders
14:09:28 <mriedem> #link Pike Review Priorities etherpad: https://etherpad.openstack.org/p/pike-nova-priorities-tracking
14:09:34 <mriedem> #link Forum planning: https://wiki.openstack.org/wiki/Forum/Boston2017
14:09:39 <edleafe> mmmmm... donuts
14:09:40 <mriedem> #link https://etherpad.openstack.org/p/BOS-Nova-brainstorming Forum discussion planning for nova (add your name if you are going)
14:09:45 <mriedem> #info Forum sessions: https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=forum
14:09:51 <mriedem> ^ is the actual for real schedule
14:10:00 <efried> mriedem I had a question there.
14:10:06 <mriedem> i'd encourage everyone to go through and start adding to their schedule
14:10:14 <johnthetubaguy> I wanted to advertise the VM & baremetal sessions
14:10:21 <mriedem> it's like 2-3 sessions to choose from for any given time slot
14:10:22 <efried> Other than sessions listed on the schedule, are there any general nova team meetups happening?
14:10:38 <mriedem> efried: nope, unless impromptu
14:10:40 <johnthetubaguy> hoping to have groups of projects, including ourselves getting feedback from operators and API users
14:10:59 <efried> k, so the BOS-Nova-brainstorming etherpad topics will be covered... when?  How?
14:11:09 <mriedem> efried: honestly i haven't looked at the schedule from a high level to see if there are any big blocks of time where we won't be in scheduled sessions
14:11:19 <mriedem> efried: some of it is in existing sessions
14:11:42 <mriedem> when i filled out my M-Th schedule though i think there was only 1 slot where i didn't plan on going to anything
14:11:46 <efried> k, prolly that etherpad needs to be gone through and links to those sessions added where available.
14:11:50 <mriedem> sure
14:11:56 <johnthetubaguy> #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18750/operating-the-vm-and-baremetal-platform-12
14:12:06 <mriedem> #action mriedem to update https://etherpad.openstack.org/p/BOS-Nova-brainstorming with actual session links
14:12:14 <johnthetubaguy> just advertising that one, lots of nova things in there, I hope
14:12:31 <mriedem> the vm/bm ones are on my schedule
14:12:56 * mriedem waits for toilet joke
14:13:09 <mriedem> anything else for the forum?
14:13:21 <mriedem> #topic Stable branch status: https://etherpad.openstack.org/p/stable-tracker
14:13:28 <mriedem> stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:13:35 <mriedem> #help Need these stable/ocata backports merged for a regression fix: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata+topic:bug/1682693
14:13:45 <mriedem> lyarwood already +2'ed those
14:13:57 <mriedem> so need another stable core to take a look, dansmith / johnthetubaguy / bauzas
14:14:02 * johnthetubaguy nods
14:14:04 <bauzas> on it
14:14:11 <mriedem> stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
14:14:28 <mriedem> not a ton there, but same regression fix
14:14:36 <mriedem> #topic subteam highlights
14:14:41 <mriedem> dansmith: cells v2
14:14:47 <dansmith> we had a meeting
14:15:00 <mriedem> which i guess i missed...
14:15:03 <mriedem> oops
14:15:09 <dansmith> discussed the stuff that is open, like the quotas set
14:15:10 <dansmith> assigned all reviews to mriedem
14:15:14 <dansmith> that was pretty much it
14:15:19 <mriedem> ok
14:15:35 <mriedem> edleafe: scheduler
14:15:40 <edleafe> Spent nearly the entire meeting discussing the spec for claiming in the scheduler.
14:15:43 <edleafe> Very productive discussion; led to better understanding of the overall process.
14:15:46 <edleafe> Not much time for anything else :)
14:15:48 <edleafe> EOM
14:15:52 <jaypipes> assigned all work to mriedem. EOM.
14:15:55 <jaypipes> job done.
14:16:12 <edleafe> jaypipes: :)
14:16:16 <mriedem> for those interested, the current snag is being discussed in the spec https://review.openstack.org/#/c/437424/5/specs/pike/approved/placement-claims.rst
14:16:41 * alex_xu just added another idea afernoon
14:16:44 <mriedem> tdurakov: live migration?
14:16:59 <cdent> "current snag" sounds scary
14:17:14 <mriedem> there have been a few snags
14:17:16 <mriedem> this is the most recent
14:17:28 <mriedem> there is a reason we haven't done claims in the scheduler before...
14:17:51 <mriedem> alex_xu: api subteam meeting highlights?
14:17:55 <alex_xu> Talk about Johnthetubaguy and sdague works with keystone team on the new design of policy stuff
14:18:03 <alex_xu> Talk about Johnthetubaguy and sdague works with keystone team on the new design of policy stuff
14:18:11 <alex_xu> cdent brings the patches for nova-api under wsgi up https://review.openstack.org/#/c/457283/  https://review.openstack.org/#/c/457715/
14:18:22 <alex_xu> sorry, copy failed
14:18:25 <alex_xu> that is all
14:18:36 <mriedem> ok thanks
14:18:58 <mriedem> we have a few api deprecation changes up for review too, so making progress early on those
14:19:33 <alex_xu> https://review.openstack.org/457181 and https://review.openstack.org/456504
14:19:35 <mriedem> i should probably also bring up the list migrations API discussion from the ML in open discussion too...
14:19:58 <mriedem> alex_xu: also https://review.openstack.org/#/c/457008/ is ready
14:20:04 <alex_xu> mriedem: cool
14:20:06 <mriedem> moving on
14:20:12 <mriedem> gibi: notifications meeting highlights?
14:20:34 <mriedem> maybe he's not here - it was a productive meeting,
14:20:46 <mriedem> we settled on what to do about instance tags in notification payloads
14:20:52 <mriedem> and we're just going to put them in the instance.update payload for now
14:21:09 <mriedem> and the instance.create payload when Kevin_Zheng adds support to tag an instance at create time
14:21:24 <mriedem> gibi is going to take over putting bdms into the payload (needed for searchlight)
14:21:44 <mriedem> we sorted out what to do with soft_delete notifications in the local delete case in the api
14:22:11 <mriedem> with osic being done, we're going to have a slump in the versioned notification work
14:22:22 <mriedem> so that's an opportunity for people looking for something to work on
14:22:37 <mriedem> efried: powervm?
14:22:48 <efried> No change since last week.  https://review.openstack.org/438119 has mriedem +2, needs other core reviews; https://review.openstack.org/438598 is ready for core reviews.
14:22:55 <efried> I know these _seem_ intimidating, but the code is SO clean and pretty; they're a joy to review.
14:23:00 <efried> No, really.
14:23:10 <mriedem> sdague: want to take a look at https://review.openstack.org/438119 ?
14:23:25 <mriedem> i'll just start harassing cores
14:23:35 <efried> Per mriedem http://lists.openstack.org/pipermail/openstack-dev/2017-April/115700.html we ought to be able to get up to console support in pike - those changes are all proposed and queued up.
14:23:43 <sdague> mriedem: will do
14:23:47 <efried> Thanks guys.
14:23:56 <mriedem> nova/cinder - current focus is still on starting the detach flows https://review.openstack.org/#/c/438750/
14:24:02 <mriedem> ^ will probably be approved today
14:24:16 <mriedem> but there are a series of these since we do detach/terminate_connection all over the place
14:24:29 <mriedem> think swap volume, migration, rebuild, etc
14:24:43 <mriedem> (not shelve offload because we're dumb...)
14:24:58 <mriedem> #topic stuck reviews
14:25:04 <mriedem> nothing on the agenda
14:25:09 <mriedem> #topic open discussion
14:25:12 <mriedem> lyarwood: you're up
14:25:17 <lyarwood> I have a specless bp for https://review.openstack.org/391597 to remove duplicate encryptor code from nova that needs approval if anyone has time - https://blueprints.launchpad.net/nova/+spec/switch-to-os-brick-encryptor-classes
14:26:18 <mriedem> -1 on the patch :)
14:26:34 <lyarwood> but +1 on the bp? ;)
14:27:12 <mriedem> probably
14:27:35 <mriedem> are there any upgrade implications with this?
14:27:50 * johnthetubaguy is curious about any config changes
14:27:52 <mriedem> or is it just the same code, but from a library now?
14:27:56 <lyarwood> mriedem: nope, it's the same code in nova and os-brick
14:28:26 <lyarwood> johnthetubaguy: AFAIK there shouldn't be any introduced by this
14:28:38 <mriedem> i don't think we had any config for any of this before anyway
14:28:46 <mriedem> this actually removes some rootwrap entries which is nice,
14:28:49 <mriedem> since brick uses privsep
14:29:14 <johnthetubaguy> I guess with both use castellan, which has the conf
14:29:20 <mriedem> ok i'm +1 on the specless bp, albeit it's late
14:29:33 <mriedem> yeah the key manager is the only thing i think
14:29:39 <mriedem> the key manager is passed into brick it looks like
14:30:25 <mriedem> johnthetubaguy: you ok with the specless bp?
14:30:37 <johnthetubaguy> yeah, happy with the concept
14:30:47 <mriedem> ok approved
14:30:53 <lyarwood> cool thanks
14:31:25 <mriedem> ok so the other thing i wanted to bring up, since it's block takashin,
14:31:48 <mriedem> is we had approved his spec to update the server migrations API to return all migration types, not just live migration
14:31:50 <mriedem> that's good,
14:31:57 <mriedem> but it also only returns in-progress live migrations,
14:32:23 <mriedem> in the ML i proposed that we return migrations of any status, and allow for a status filter query parameter if the client wants to filter on the server side
14:32:32 <mriedem> operators seemed to like that idea
14:32:43 <mriedem> since instance actions doesn't provide the same level of detail that we get from the migrations api
14:32:43 <johnthetubaguy> yes, I think sdague mentioned it was originally planned not to replace instance_actions or the "forth coming" tasks API
14:32:58 <mriedem> after 3 years of hearing about the tasks api,
14:33:03 <mriedem> i don't give it any mind anymore
14:33:27 <johnthetubaguy> but give thats a touch delayed... yeah, all status makes sense, if we are careful defining the different status codes and what they mean
14:33:59 <mriedem> i figured we'd have a meta value for the status filter parameter called "inprogress" or something
14:34:11 <mriedem> since there are a few migration states that fall under that umbrella
14:34:35 <mriedem> i guess i'm looking for general agreement, and if so, i can amend the spec
14:34:51 <mriedem> i agree it's late, but we already approved takashin's spec but i've -2ed the code until we sort out this amendment idea,
14:35:04 <mriedem> in other words, i don't want to land this microversion, just to add another microversion later to expose all statues
14:35:06 <mriedem> *status
14:35:25 <mriedem> alex_xu: takashin: do you have any thoughts?
14:35:59 <alex_xu> I'm ok with that
14:36:13 <takashin> mriedem: the spec is for "abort cold migration" function.
14:36:28 <mriedem> takashin: the abort cold migration spec is for abort cold migration :)
14:36:33 <mriedem> this spec is about listing migrations
14:36:45 <mriedem> we shouldn't munge the two concepts in my opinion
14:36:50 <mriedem> as it makes for a bad api experience
14:37:15 <takashin> mriedem: We have to list the migrations to abort cold migration.
14:37:31 <mriedem> takashin: i agree
14:37:38 <takashin> mriedem: So "in-progress" migration should be listed.
14:37:43 <mriedem> takashin: and it will be
14:37:56 <mriedem> but so will completed migrations if you don't filter on status
14:38:18 <mriedem> ^ is what i'm proposing
14:38:48 <mriedem> so that we can get out of this meeting, i can work on amending the spec with how i think this should look, and we can discuss it in the review
14:39:05 <alex_xu> or in default we only show in-progress migration, with flag all=true to show all the migrations
14:39:17 <alex_xu> yea
14:39:34 <mriedem> alex_xu: i'm not a fan of that - we don't only list ACTIVE servers by default
14:39:42 <mriedem> anyway, we can discuss when i actually write something up
14:39:44 <takashin> There is a os-migrations API.
14:39:56 <mriedem> takashin: which says it's frozen
14:39:56 <takashin> It has been frozen.
14:40:26 <mriedem> takashin: alex_xu: let's discuss this in -nova after the meeting
14:40:29 <mriedem> did anyone have anything else?
14:40:44 <mriedem> nope. ok, thanks everyone
14:40:47 <mriedem> #endmeeting