21:02:50 #startmeeting nova 21:02:51 Meeting started Thu Dec 8 21:02:50 2016 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:52 ooh, that was sneaky! 21:02:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:55 The meeting name has been set to 'nova' 21:03:03 well we should have some super interesting logs 21:03:03 o/ 21:03:05 o/ 21:03:12 \o 21:03:12 :P 21:03:15 o/ 21:04:02 * Vek waves 21:04:29 ok so let's get started 21:04:31 #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 21:04:42 #topic release news 21:04:51 #link Ocata release schedule: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule 21:05:06 #info next thursday 12/15 is the o-2 milestone 21:05:16 #link Ocata blueprints https://blueprints.launchpad.net/nova/ocata 21:05:22 #info 69 total blueprints, 8 implemented, 10 not started, 37 need code review, 10 implemented 21:05:31 oops some stale data in there 21:05:49 so still a few blueprints that haven't started 21:05:53 which is concerning 21:06:02 i tried bugging some people in irc the other day 21:06:16 but honestly we have enough code up for review for other blueprints at this point i'm not going to chase people much 21:06:41 any questions? 21:06:51 #topic bugs 21:07:20 sdague helped out with triage yesterday and took a pretty good chunk out of the new bugs list, so thanks there 21:07:33 one i came across which isn't really new but wasn't being worked is https://launchpad.net/bugs/1633734 21:07:33 Launchpad bug 1633734 in OpenStack Compute (nova) "ValueError: Field `instance_uuid' cannot be None" [High,Confirmed] 21:07:41 so ^ is an upgrade issue from mitaka to newton 21:07:50 i've started a repro patch here https://review.openstack.org/#/c/408727/ 21:08:09 it's tricksy, and i think we need an invalid data purge migration in newton to handle it 21:08:20 but i'm not sure if it's an offline data migration or online 21:08:26 so need to talk to some people about that later 21:08:49 otherwise we don't have any critical bugs 21:09:04 gate status and 3rd party ci status are relatively uneventful 21:09:10 i've noticed the intel nfv ci went away 21:09:13 wznoinsk: are you around? 21:09:32 i'll follow up on that later 21:09:40 i know they were working through some issues with their multinode job 21:09:46 anyone else for bugs? 21:09:55 Yes should be back tomorrow 21:10:01 wznoinsk: cool 21:10:11 #topic reminders 21:10:19 #link Ocata review priorities https://etherpad.openstack.org/p/ocata-nova-priorities-tracking 21:10:30 i haven't been through ^ lately so know how up to date it is 21:10:34 Hi im back 21:10:41 cdent has been sending out priorities for resource provider work in the ML 21:11:02 #topic stable branch status 21:11:16 not much to report here except liberty should be eol soon 21:11:21 tonyb was putting in the request to infra for that last night 21:11:43 Can I propose an idea? 21:11:45 and lyarwood cleaned out a lot of stable/mitaka stuff that wasn't appropriate 21:11:59 kristian__: does it have to do with stable branches? 21:12:09 kristian__: because if not, please save it for open discussion 21:12:28 its about gpu passthrough 21:12:32 yeah so not right now 21:12:39 any questions on stable? 21:12:54 moving on 21:12:58 #topic subteam highlights 21:13:26 for cellsv2, the main review focus right now is on the series starting here https://review.openstack.org/#/c/406380/ 21:13:44 melwitt: was there anything else from the cells meeting yesterday you wanted to bring up? like consoleauth or quotas? 21:14:26 sure, I can note that for cells v2 we need to change the deployment assumption from consoleauth service at the top to consoleauth service per cell 21:14:41 #info for cells v2 we need to change the deployment assumption from consoleauth service at the top to consoleauth service per cell 21:15:00 nothing yet on quotas, I'll have something next week 21:15:12 melwitt: do we have changes we need to work for consoleauth for cells v2 right now? 21:15:54 yes, brought up in the meeting was that we need the message queue switching stuff in consoleauth/rpcapi.py like we have in compute/rpcapi.py. dtp volunteered to add that 21:16:23 #info dtp volunteered to work on adding mq switching to consoleauth/rpcapi.py 21:16:29 cool 21:16:39 moving on 21:16:41 edleafe: scheduler? 21:16:45 Discussed whether optional placement DB was going to make it into Ocata. Decision was "meh" 21:16:48 Discussed remotable vs non-remotable, but that was pretty quiet because bauzas wasn't there :) 21:16:51 Agreed to bump the limit on retries for ResourceClass ID generation, with logging added to see if we ever hit it. 21:16:54 Didn't argue the GET vs. POST and/or new resource for querying resource providers - again, no bauzas 21:16:57 done 21:17:06 the non-remotable patch is up from cdent 21:17:11 oh man, missed the meeting 21:17:14 \o 21:17:16 i'm also meh on optional placement db 21:17:28 bauzas: we missed you too :) 21:17:51 and jaypipes has the GET /resource_providers filtering patch up, i just haven't gotten there yet 21:18:04 more info on the GET vs POST thing is in the dev ML 21:18:11 tdurakov: are you around? 21:18:12 mriedem: I squashed the patch 21:18:15 bauzas: yup 21:18:36 i don't have any notes for the live migration meeting 21:18:42 so moving on 21:18:48 sdague: did you make the api meeting this week? 21:19:13 re: api, the last remaining spec we need for ocata is https://review.openstack.org/#/c/393205/ 21:19:21 and because i'm a terrible person i haven't gone back to review it yet 21:19:22 but need to 21:19:26 as does everyone else 21:19:44 that's the one about restricting the server list sort/filter parameters 21:20:05 thanks for Kevin_Zheng for continuing to update the spec 21:20:10 s/for/to/ 21:20:16 moving on 21:20:23 sriov/pci - lbeliveau? 21:20:29 is that bi-weekly now and this wasn't the week? 21:20:45 i know moshele wants reviews on the pci whitelist regex patch 21:20:59 https://review.openstack.org/#/c/199488/ 21:21:04 looks like jay got a review on it today 21:21:19 mriedem: yeh, still working through that one. 21:21:21 ok moving on again (damn quiet in here today) 21:21:27 jaypipes: thanks 21:21:35 gibi: are you around for notifications highlights? 21:21:43 mriedem: I'm still chugging through mdbooth's libvirt imagebackend patch series. 21:21:46 mriedem: ping me when I can post my idea 21:21:54 mriedem: and a few of the flavor notifications series. 21:22:12 yar 21:22:21 so on the notification subteam, they have things ready for review in https://etherpad.openstack.org/p/ocata-nova-priorities-tracking 21:22:23 L177 21:22:36 they are pretty mechanical and easy to review for people looking for something to review 21:23:01 #topic stuck reviews 21:23:16 nothing on the agenda, did anyone have anything they wanted to bring up? 21:23:31 #topic open discussion 21:23:35 kristian__: go 21:23:43 #idea Can there be a metadata option to attach gpu as a main display source? 21:24:03 as in image metadata? 21:24:34 no in a flavor 21:24:44 so a flavor extra spec 21:24:50 yes 21:25:01 which virt drivers support that? 21:25:25 i.e. we generally want things like this to be supportable across the hypervisor drivers 21:26:31 don't know but it should be possible on vanilla qemu/kvm, because I have it running like that in proxmox and before that normally on arch as a "second pc" 21:26:32 kristian__: i don't know the details, it'd probably be something that needs a spec 21:26:51 to detail how this would be handled in the libvirt driver 21:27:05 and then get the other virt driver maintainers to weigh in on if they could support the feature too 21:28:00 kristian__: do you have any other questions about that? 21:28:09 note that we're not accepting new specs for the current ocata release 21:28:11 it should work natively but novnc will not work 21:28:14 so this would have to be proposed for the pike release 21:28:23 ok np 21:28:41 the nova-specs repo has the pike structure now though so you can start working on the spec and propose it for the next release 21:28:51 details about novnc not working would be good to have in there 21:29:16 sahid might be a good person on the libvirt driver team to talk to about this 21:29:31 ok, anyone else for anything else? 21:29:39 mriedem: not from me. 21:29:50 me neither 21:29:54 mriedem: could you propose that spec? because Im not a python and or openstack dev 21:30:00 kristian__: nope 21:30:13 kristian__: you could write it up as a backlog spec 21:30:28 backlog specs in the nova-specs repo are just basically laying out a high level idea with some details, 21:30:41 mriedem: where? 21:30:42 and then if a developer is interested in working on implementing it, they can take the backlog spec and flesh it out 21:30:54 kristian__: https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html 21:31:26 the spec template is a guide for what to put in the doc, and where you can stop if you're just doing a backlog spec 21:31:47 backlog specs aren't tied to a given release, they are just a way to put out a feature request / idea 21:31:56 you don't need to know python, just to write up the idea 21:32:20 kristian__: if you have more questions you can ask in the #openstack-nova channel after the meeting 21:32:25 which i'm going to end, now 21:32:27 ok 21:32:28 thanks everyone 21:32:31 #endmeeting