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