14:00:01 <bauzas> #startmeeting nova
14:00:02 <openstack> Meeting started Thu Dec  1 14:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'nova'
14:00:09 <mriedem> o/
14:00:10 <takashin> o/
14:00:13 <alex_xu> o/
14:00:13 <bauzas> howdy
14:00:19 <raj_singh> o/
14:00:20 <gibi> o/
14:00:27 <tdurakov> o/
14:00:29 <sfinucan> o/
14:00:34 <bauzas> mriedem is kinda AFK for the next mins, so I'm your waiter for today
14:01:11 <bauzas> okay, let's start with the agenda
14:01:16 <bauzas> https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:29 <bauzas> #topic Release News
14:01:35 <bauzas> #link Ocata release schedule: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule
14:01:36 <johnthetubaguy> o/
14:01:55 <mriedem> 12/15 is o-2
14:01:55 <bauzas> nothing really special this week
14:01:59 <lyarwood> o/
14:01:59 <mriedem> is the next upcoming milestone
14:02:00 <bauzas> yeah that
14:02:07 <mriedem> so 2 weeks from o-2
14:02:15 <bauzas> #info 2 weeks from ocata-2 milestone
14:02:36 <bauzas> so, folks, gentle reminder that you should really start implementing :)
14:02:45 <bauzas> soo, good for
14:02:51 <bauzas> #link Ocata blueprints https://blueprints.launchpad.net/nova/ocata
14:03:01 <bauzas> #info 69 total blueprints, 8 implemented, 14 not started, 36 need code review
14:03:29 <bauzas> as mriedem said in his e-mail, we would need to merge 1 BP per day to have all of them implemented
14:05:10 <bauzas> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/108089.html
14:05:40 <bauzas> " If you have an approved blueprint/spec but don't have code up for review  yet, you'd better get started on that. "
14:05:40 <bauzas> "  If you have blueprint code up for review and actually get review  comments, be quick about addressing those comments. Follow up in IRC if  it requires a higher frequency discussion than code review allows. "
14:05:44 <bauzas> any comments ?
14:06:01 <bauzas> okay, next topic
14:06:11 <bauzas> #topic Bugs
14:06:32 <bauzas> we have no critical bugs AFAIK
14:06:40 <bauzas> we had a gate failure this morning tho
14:06:53 <bauzas> and we had a problem last week with postgre
14:07:06 <bauzas> tdurakov: is the live-migrate job fixed ?
14:07:10 <mriedem> yeah
14:07:10 <mriedem> https://review.openstack.org/#/c/405196/
14:07:13 <bauzas> \o/
14:07:14 <mriedem> thanks tdurakov
14:07:16 <tdurakov> looks so
14:07:16 <mriedem> i broke it :)
14:07:19 <tdurakov> np
14:07:23 <bauzas> I haven't checked logstash
14:07:23 * edleafe wanders in late
14:07:31 <bauzas> tdurakov: yup, thanks for that <3
14:07:57 <bauzas> nothing on the 3rd CI side ?
14:08:05 <bauzas> #info Need to move 3rd party CI to use Neutron as we're moving off nova-network.
14:08:13 <bauzas> mriedem wrote again an email :p
14:08:44 <bauzas> #link http://lists.openstack.org/pipermail/openstack-dev/2016-December/108246.html
14:08:49 * johnthetubaguy nods with great respect at all the email writing
14:09:11 <bauzas> heh
14:09:30 <bauzas> so, tl;dr: in case you have a 3rd CI using n-net, please use rather neutron now
14:09:39 <bauzas> or, we would put your job as non-voting
14:09:42 <johnthetubaguy> else you don't have a passing CI any more
14:09:51 <bauzas> yeah
14:09:52 <johnthetubaguy> (soon)
14:10:08 <bauzas> in other words, please help us use neutron :)
14:10:28 <bauzas> no bugs we missed ?
14:10:42 <bauzas> I don't think I should be discussing about the postgre bug honestly
14:11:09 <bauzas> because it's fixed, and because that's something we agreed
14:11:14 <bauzas> so, moving on
14:11:38 <bauzas> #topic Reminders
14:11:44 <bauzas> #link Ocata review priorities https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
14:12:03 <bauzas> gentle reminder for using that ^ as a way to review subteam patches and priorities
14:12:20 <bauzas> also, subteams need to make sure that etherpad is not stale
14:12:28 <bauzas> for their own provided changes
14:13:08 <bauzas> I can see that etherpad quite good for at least cellsv2 and scheduler
14:13:08 <edleafe> Yeah, I'll check for scheduler staleness today
14:13:16 <bauzas> edleafe: thanks
14:13:20 <bauzas> ... which leads to me to
14:13:22 <sfinucan> Shameless plug for a corresponding patch in nova-specs https://review.openstack.org/#/c/400326/
14:13:37 <sfinucan> ...assuming we're still populating nova-specs with priorities
14:13:54 <johnthetubaguy> oh, cool, I mean to check on that earlier
14:13:58 <johnthetubaguy> meant
14:14:01 <bauzas> sfinucan: you make a good point, I actually proposed myself for writing the pike structure as well :/
14:14:10 <bauzas> I'll do that right after the meeting, not a big deal
14:14:12 <sfinucan> bauzas: I just did that :P
14:14:22 <bauzas> sfinucan: okay, change ? :)
14:14:47 <mriedem> sfinucan: https://review.openstack.org/#/c/404456/
14:15:08 <mriedem> the pike structure is different from the ocata priorities
14:15:18 <bauzas> mriedem: heh, okay
14:15:21 <sfinucan> mriedem: I'll note that mine's a week older
14:15:24 * bauzas adding a new tabn
14:15:24 <sfinucan> but I digress :)
14:15:31 <bauzas> let's discuss that offline
14:15:44 <bauzas> but yeah, we need to sort out that thing, agreed
14:15:58 <bauzas> #topic Stable branches
14:16:09 <bauzas> #link https://etherpad.openstack.org/p/stable-tracker
14:16:17 <bauzas> what's up for newton ?
14:16:30 <mriedem> lyarwood is active on those
14:16:32 <bauzas> do we plan a point release soon ?
14:16:38 <lyarwood> ~10 +2'd reviews that need some core love if anyone has time
14:16:41 <bauzas> do you folks need reviews ? I assume yes
14:16:45 <bauzas> oaky
14:16:53 <mriedem> might release around o-2
14:16:56 <lyarwood> we should likely think about a release after that
14:16:57 <lyarwood> yeah
14:17:01 <bauzas> cool
14:17:18 <bauzas> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
14:17:21 <johnthetubaguy> lyarwood: do ping me in the mornings if it looks like that needs more love, I keep forgetting to go digging in there :(
14:17:35 <bauzas> I cann see a lot of them needing +W indeed
14:17:47 <lyarwood> johnthetubaguy: thanks, will do :)
14:17:50 <bauzas> which is cool, thanks lyarwood for paying attention
14:18:01 <johnthetubaguy> +1
14:18:10 <bauzas> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/mitaka,n,z
14:18:40 <lyarwood> we should really clear that out tbh
14:18:42 <mriedem> lots of garbage there...
14:18:44 <bauzas> lyarwood: how is CI for mitaka ?
14:18:55 <bauzas> I can see two -1s recently
14:19:00 <lyarwood> bauzas: no idea for mitaka as there's nothing useful that's landing atm
14:19:01 <bauzas> I mean two Jenkins -1s
14:19:06 <lyarwood> bauzas: these are all old reviews iirc
14:19:11 <bauzas> okay, so yeah we could clean up those
14:19:19 <johnthetubaguy> abandon hammer time?
14:19:33 <lyarwood> happy to do that if people agree to it
14:19:40 <bauzas> most of them are already older than 1 month
14:19:47 <bauzas> so yeah, lyarwood you could abandon them
14:19:56 <johnthetubaguy> yeah, just leave a nice note I guess
14:20:06 <lyarwood> ack I'll do that now, thanks
14:20:08 <bauzas> heh, hopefully :)
14:20:15 <bauzas> lyarwood: thanks
14:20:27 <bauzas> #topic Subteam Highlights
14:20:35 <bauzas> okay, let's begin the show !
14:20:57 <bauzas> for cells v2, I can see some notes from mriedem
14:21:04 <bauzas> thanks for his gracious attention
14:21:25 <bauzas> #help Need reviews for Cellsv2 https://review.openstack.org/#/c/399710/
14:21:56 <bauzas> "  There might be some rough waters with cells v1 when we move  instance creation to conductor, but we'll see how bad that looks when we  get there. Might require some cells v1 conditional hackery."
14:22:03 <bauzas> which is understandable to me
14:22:23 <bauzas> because we have a separate path for creating an instance with cellsv1
14:22:33 <bauzas> mriedem: if you're still there, I'd be more interested in details
14:22:57 <bauzas> but we can put that offline
14:23:14 <bauzas> " melwitt is going to check to see what's needed for consoleauth, if anything."
14:23:28 <bauzas> interesting point as well
14:23:44 <bauzas> if folks don't have comments or concerns for cellsv2, let's move on
14:24:07 <bauzas> edleafe: your call :)
14:24:15 <edleafe> Quick meeting - the only controversy is whether or not we will be good OpenStack citizens and follow API WG guidelines regarding GET vs. POST for filtering requests.
14:24:18 <edleafe> Otherwise, just a general sanity check on our progress
14:24:21 <edleafe> that's it
14:24:26 <bauzas> we're good citizens
14:24:30 <edleafe> :)
14:24:57 <bauzas> but that doesn't necessarly mean that we can't disagree with our guidelines
14:25:08 <bauzas> don't folks remember that I'm French ?
14:26:19 <mriedem> cdent also has more RP updates here http://lists.openstack.org/pipermail/openstack-dev/2016-November/107982.html
14:26:20 <bauzas> edleafe: apart of this, any other big things to mention ? I don't think so
14:26:24 <bauzas> oh right
14:26:31 <edleafe> nope
14:26:42 <mriedem> https://review.openstack.org/#/c/391918/ is also ready to go
14:26:45 <bauzas> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107982.html for people wanting to get more details about RP progress
14:26:48 <mriedem> need to keep the resource class stuff moving
14:27:06 <bauzas> yeah
14:27:15 <bauzas> I need to look at those patches asap
14:27:26 <bauzas> moving on
14:27:40 <bauzas> Live Migration, tdurakov ?
14:27:54 <bauzas> you had a meeting AFAIR
14:27:58 <tdurakov> bauzas: updated agenda, nothing special for today
14:28:32 <bauzas> okay, seems like you folks are aligned with the priorities etherpad, cool
14:29:04 <bauzas> tdurakov: I'm still a bit afraid of us being dependent on libvirt not supporting unicode, but okay :)
14:30:04 * dansmith staggers in late
14:30:08 <mriedem> moving on?
14:30:11 <bauzas> alex_xu, sdague, API ?
14:30:16 <alex_xu> The hot topic still is query parameter https://review.openstack.org/#/c/393205/
14:30:28 <alex_xu> The spec updated for ignoring the filter/sort keys which we think is bad, instead of returning 400. This is good for not break the client directly. Also add policy rule to ensure those bad filter/sort for people really depend on it.
14:30:43 <alex_xu> Also change the strategy a little for which filter/keys we should keep, after figure out more how index can help us.
14:30:57 <bauzas> oh okay
14:31:01 <mriedem> sdague, dansmith and i talked a bit about that yesterday too,
14:31:02 <alex_xu> then looking for feedback on the spec
14:31:07 <mriedem> i need to get back to reviewing that one
14:31:12 <alex_xu> mriedem: thanks
14:31:20 <bauzas> cool
14:31:37 <bauzas> alex_xu: I guess you have code up against that one ?
14:31:47 <bauzas> that could help reviewing the spec
14:31:53 <alex_xu> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/consistent-query-parameters-validation
14:32:03 <bauzas> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/consistent-query-parameters-validation
14:32:04 <sdague> alex_xu: ignoring instead of 400 seems safest here
14:32:06 <alex_xu> the base spec have code patch now ^
14:32:13 <bauzas> alex_xu: great
14:32:17 <alex_xu> sdague: yea
14:32:19 <johnthetubaguy> sdague: +1
14:32:36 <bauzas> okay, moving on
14:32:45 <bauzas> SRIOV, moshele, sfinucan ?
14:32:59 <bauzas> I can see sfinucan writing some email too
14:33:17 <lbeliveau> worth mentionning that we are thinking about moving the meetings to bi weekly
14:33:22 <bauzas> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108267.html
14:33:37 <bauzas> lbeliveau: okay, not yet settled ?
14:33:53 <lbeliveau> I think so :)  moshele is supopsed to send an email soon
14:34:19 <sfinucan> ...and the only thing I can think to point out is that jaypipe's has his resource provider patches for SR-IOV devs up
14:34:33 <bauzas> lbeliveau: okay, just make sure you update the wikipage and provide a patch against eavesdrop
14:34:39 <sfinucan> or he did - there were issues with some of them. Either way, worth looking at
14:34:58 <lbeliveau> yeap
14:35:04 <bauzas> sfinucan: the nested resource providers ?
14:35:32 <sfinucan> yessir - those ones
14:35:34 <bauzas> anyway, moving on
14:35:35 <sfinucan> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-resource-providers
14:35:42 <bauzas> cool, thanks
14:35:49 <bauzas> gibi, notifications
14:35:53 <gibi> notification transformation work progresses steadily
14:35:55 <bauzas> ?
14:35:57 <bauzas> okay
14:36:01 <gibi> the ocata priority etherpad is up to date with patches waiting for core review
14:36:05 <bauzas> nothing really we should care of ?
14:36:09 <bauzas> sweet
14:36:22 <gibi> the searchlight related notification bp got an assignee
14:36:32 <gibi> #link https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
14:36:40 <gibi> I hope we will see the patches soon
14:36:45 <bauzas> cool
14:36:58 <bauzas> let's move on
14:37:02 <bauzas> #topic Stuck Reviews
14:37:11 <bauzas> I can't see any stuck review mentioned in the agenda
14:37:22 <bauzas> so, next topic unless someone shouts
14:37:36 <bauzas> #topic Open Discussion
14:37:54 <bauzas> flood is yours, folks, I don't have something specific in mind
14:38:01 <bauzas> and nothing is written in the agenda
14:38:29 <bauzas> that said, I maybe have one point about the placement API being mandatory for Ocata, and when we send that signal
14:39:21 <bauzas> do we assume that the placement API will become mandatory once the scheduler begins consuming those resources, or when we have the resource tracker stopping reporting usage the old way ?
14:39:31 <bauzas> I tend for the former
14:39:33 <johnthetubaguy> is there some block migration check we need to land first?
14:39:45 <johnthetubaguy> blocking
14:39:52 <dansmith> johnthetubaguy: we have to be able to actually support it first
14:40:09 <dansmith> johnthetubaguy: and we were going to do it with the "nova-manage upgrade status" command
14:40:10 <edleafe> bauzas: obviously it has to be mandatory after the second case
14:40:15 <dansmith> like an "all things are go for upgrade"
14:40:19 <johnthetubaguy> dansmith: thats probably a good place to start
14:40:26 <johnthetubaguy> oh, I like that
14:40:42 <bauzas> dansmith: I missed that specific command
14:40:44 <dansmith> johnthetubaguy: it's a bigger thing than just a single db, so we have to do it outside a migration I think
14:40:48 <johnthetubaguy> I got a request from someone about, "tell me if all the DB migrations are done"
14:40:58 <bauzas> dansmith: is that something planned ?
14:41:02 <johnthetubaguy> dansmith: yeah, that can cover the cells things too I guess
14:41:04 <dansmith> johnthetubaguy: yeah, that command will be useful for all phases I think
14:41:12 <johnthetubaguy> dansmith: +1 sounds good
14:41:16 <dansmith> bauzas: it's just an idea I had -- we have discussed it a couple times
14:41:25 <bauzas> dansmith: I like that idea tbh
14:41:45 <bauzas> like "it's green, you can do that" IIUC ?
14:41:55 <dansmith> yeah
14:42:03 <dansmith> or "it's done, nothing else to do" on the other side
14:42:05 <bauzas> then I'm totally cool with that
14:42:45 <bauzas> dansmith: that would mean we would require the placement API to be started before you deploy Ocata, right?
14:42:55 <dansmith> that's what we've been discussing anyway
14:43:01 <bauzas> yeah, I know
14:43:12 <bauzas> I was more concerned by when we would signal that or how
14:43:18 <edleafe> dansmith: also, "you need to do a, b, and c first"
14:44:18 <bauzas> anyway, I'm done
14:44:27 <bauzas> does someone has something to discuss ?
14:45:08 <bauzas> I really want to save us 15 mins * number of participants
14:45:21 <bauzas> thanks folks
14:45:27 <bauzas> #endmeeting