14:00:15 <johnthetubaguy> #startmeeting nova
14:00:19 <openstack> Meeting started Thu Nov 17 14:00:15 2016 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'nova'
14:00:23 <macsz> \o
14:00:26 <takashin> o/
14:00:27 <bauzas> \o
14:00:29 <alex_xu> o/
14:00:33 <diana_clarke> o/
14:00:34 <johnthetubaguy> hello from your guest host for today
14:00:39 * bauzas will have to bail out early by 1425UTC
14:00:41 <cdent> o/
14:00:41 <raj_singh> o/
14:00:44 <sfinucan> howdy
14:00:50 * mriedem lurks
14:01:02 <johnthetubaguy> #topic Release News
14:01:10 <johnthetubaguy> #link Ocata release schedule: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule
14:01:19 <johnthetubaguy> #info Today (11/17) is the o-1 milestone and spec approval freeze.
14:01:20 <edleafe> \o
14:01:28 <johnthetubaguy> #help Need to create the pike structure for the nova-specs repo so we can move specs that didn't get merged for ocata.
14:01:39 <johnthetubaguy> any volunteers for that?
14:01:43 <bauzas> I can
14:01:47 <johnthetubaguy> cool
14:01:53 <johnthetubaguy> #action bauzas to help with pike structure
14:02:00 <lyarwood> o/
14:02:09 <johnthetubaguy> any more for any more on the release details?
14:02:21 <johnthetubaguy> #topic Bugs
14:02:41 <johnthetubaguy> no critical bugs listed right now
14:02:50 <johnthetubaguy> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:02:54 <bauzas> mriedem: lemme know when you want to cut o-1
14:03:09 <johnthetubaguy> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:03:16 <johnthetubaguy> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
14:03:23 <mriedem> bauzas: did it yesterday
14:03:33 <bauzas> mriedem: oh okay
14:03:43 <mriedem> bauzas: https://review.openstack.org/#/c/398537/
14:03:56 <johnthetubaguy> #link https://git.openstack.org/cgit/openstack/nova/tag/?h=15.0.0.0b1
14:04:02 <bauzas> \o/
14:04:18 <johnthetubaguy> #info we cut o-1
14:04:32 <bauzas> I haven't reviewed the release notes, but that looks nice anyway
14:04:34 <johnthetubaguy> so anything on bugs and gate status folks want to cover?
14:05:43 <johnthetubaguy> #topic Reminders
14:05:48 <johnthetubaguy> #link Ocata review priorities https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
14:06:06 <johnthetubaguy> #topic Stable branch status
14:06:16 <johnthetubaguy> #link https://etherpad.openstack.org/p/stable-tracker
14:06:33 <mriedem> grenade job in stable/newton is broken by yours truly
14:06:36 <mriedem> lyarwood has a fix up
14:06:47 <mriedem> https://review.openstack.org/#/c/398920/
14:07:15 * gibi joined a bit late
14:07:37 <bauzas> mmmm, okay
14:07:39 <johnthetubaguy> ah, good call out
14:07:41 <bauzas> I'll review the change
14:07:50 <bauzas> so, xenial doesn't work with stable/newton ?
14:07:55 <lyarwood> stable/mitaka
14:08:02 <lyarwood> for the initial install
14:08:04 <mriedem> grenade on newton starts on mitaka
14:08:09 <mriedem> it's weird
14:08:13 <bauzas> oh snap, yeah
14:08:19 <mriedem> and mitaka is trusty
14:08:26 <mriedem> non-grenade on newton is xenial
14:08:26 <bauzas> yeah, you're right, dudes
14:08:31 <bauzas> I forgot about that
14:08:38 <bauzas> for full grenade then
14:09:00 <bauzas> but okay, I see, +1d it
14:09:08 <lyarwood> bauzas: thanks
14:09:09 <johnthetubaguy> cool, lets keep rolling forward then
14:09:14 <johnthetubaguy> #topic Subteam Highlights
14:09:24 <johnthetubaguy> Cells v2?
14:09:33 <mriedem> there was no meeting
14:09:37 <mriedem> just need reviews
14:09:44 <johnthetubaguy> ah, right
14:09:51 <johnthetubaguy> scheduler?
14:09:53 <edleafe> Clarified that there will be no impact to the CachingScheduler when we switch the FilterScheduler to get a reduced number of hosts from the Placement API.
14:09:55 <mriedem> starts here https://review.openstack.org/#/c/394656/
14:09:56 <edleafe> Agreed that the *use* of CoreFilter, RAMFilter and DiskFilter will be deprecated, and not the filters themselves, as they are used by other schedulers.
14:09:59 <edleafe> Discussed the doc needs; agreed that the API is simple enough (now) to not require automation for creating the docs.
14:10:02 <edleafe> That's it.
14:10:21 <bauzas> reviews as well are appreciated. :)
14:10:28 <johnthetubaguy> edleafe: so the reduced list will totally break the caching scheduler, I believe, we should catch up about that
14:10:28 <mriedem> edleafe: oh that reminds me,
14:10:49 <mriedem> we have a doc for placement API microversions now, like the compute REST API doc for microversions, the history doc
14:10:51 <bauzas> johnthetubaguy: I modified the spec, you can comment on that
14:10:59 <mriedem> we should make sure microversion changes to the placement API are also updating that doc
14:10:59 <edleafe> johnthetubaguy: the point is that we agreed to make it so the change doesn't affect the host list for CachingScheduler
14:11:09 <johnthetubaguy> bauzas: yeah, I should go re-read that, by my eyes are so spec-ed out right now
14:11:24 <bauzas> we haven't yet provided a microversion for the placement API, right?
14:11:25 <edleafe> mriedem: ah, good point. I'll add it to the agenda for Monday
14:11:26 <johnthetubaguy> edleafe: ah, yep, thats what I was remembering from that, all good
14:11:33 <mriedem> bauzas: there are 2 changes up for microversions for placement
14:11:34 <edleafe> to make sure everyone is aware
14:11:35 <bauzas> anyway, we're diverging
14:11:37 <mriedem> for aggregates and resource classes
14:11:50 <bauzas> mriedem: cool, will dig into
14:12:32 <johnthetubaguy> so Live Migration?
14:12:43 <mriedem> CI is in progress, also several patches for serial-console are on review
14:12:44 <johnthetubaguy> I think that was a short one?
14:12:52 <mriedem> ^ is what tdurakov passed on
14:13:00 <johnthetubaguy> API
14:13:03 <alex_xu> It is all about the priority task: the validation of query parameters.
14:13:08 <alex_xu> #link https://review.openstack.org/388518
14:13:14 <alex_xu> the base spec is merged
14:13:17 <johnthetubaguy> just got one half of that merged I think
14:13:29 <alex_xu> #link https://review.openstack.org/393205
14:13:41 <alex_xu> yea, ^ we need help on the second one
14:13:47 <johnthetubaguy> the second one could do with someone who is good at DB optimization
14:13:56 <johnthetubaguy> filters vs sorts and indexes
14:14:09 <mriedem> that would be mr jay
14:14:18 <johnthetubaguy> yeah, we should ping him again
14:14:34 <johnthetubaguy> I tried to ask some folks on our side, will ping them again too
14:14:35 * alex_xu begin to hunt jay whole day
14:14:47 <alex_xu> johnthetubaguy: thanks
14:15:08 <johnthetubaguy> SR-IOV/PCI?
14:15:17 <johnthetubaguy> moshele?
14:15:41 <johnthetubaguy> Notifications?
14:15:42 <johnthetubaguy> gibi?
14:15:49 <sfinucan> johnthetubaguy: I didn't attend, but there wasn't much on SR-IOV/PCI front
14:15:54 <sfinucan> (having read the logs)
14:16:01 <sfinucan> Mostly spec reviews and bug fixes
14:16:15 <mriedem> for sriov
14:16:22 <mriedem> moshele: wznoinsk: would like to get https://review.openstack.org/#/c/182242/ in
14:16:24 <mriedem> the spec i mean
14:16:29 <moshele> yes
14:16:35 <mriedem> the code is pretty self-contained, i looked at it yesterday,
14:16:45 <mriedem> it's super nfv specific, single-tenant non-cloud
14:16:48 <moshele> and there are 2 spec around  NUMA
14:16:49 <gibi> johnthetubaguy: there was a short notification meeting as nobody showed up
14:16:58 <mriedem> but as long as the unicorn is confined to a small space in nova i'm less worried about it
14:17:15 <sfinucan> mriedem: Yup, that spec + the two NUMA ones moshele refers to
14:17:21 <sfinucan> all have code, iirc?
14:17:45 <mriedem> so i agree to budge a bit on one thing and i'm hammered with 2 more?!
14:18:05 <edleafe> mriedem:  when will you ever learn?
14:18:15 <sfinucan> ^ my thoughts exactly :)
14:19:06 <mriedem> let's move on
14:19:12 <johnthetubaguy> yeah
14:19:18 <johnthetubaguy> #topic Open Discussion
14:19:26 <johnthetubaguy> there was nothing in the stuck list, so jumping on ward
14:19:34 <johnthetubaguy> (mriedem) What to do about file injection? http://lists.openstack.org/pipermail/openstack-dev/2016-November/107195.html
14:19:42 <mriedem> yeah so not a lot of response there,
14:19:54 <mriedem> except a confirmation that the localfs file injection code is a security issue,
14:20:01 <mriedem> so i think we should deprecate it in ocata, remove in pike,
14:20:16 <mriedem> the other questions are around what deprecating file injection in the API would look like, i've proposed what i think we'd do,
14:20:21 <johnthetubaguy> yeah, we keep forgetting to kill that thing
14:20:24 <mriedem> i was looking to get some ops feedback but none came
14:20:38 <johnthetubaguy> #action deprecate localfs file injection in ocata, remove in pike
14:20:42 <mriedem> basically is there anything you can't do with config drive that you can with file injection? and if not, then we deprecate it in the API
14:20:58 <lyarwood> mriedem: so I was trying to do the same with cryptsetup a while ago http://lists.openstack.org/pipermail/openstack-dev/2016-November/106956.html
14:21:07 <lyarwood> mriedem: nothing back from the ops list thus far
14:21:35 <mriedem> lyarwood: i'd hit up dane-ficther on that one
14:21:40 <mriedem> or the other john hopkins people
14:21:57 <bauzas> the security risk is much more important than any usecase that could be worked around using other ways
14:21:58 <lyarwood> mriedem: ah good idea, thanks
14:22:21 <bauzas> so I'm +2 on deprecating it, and discuss on the possible missing usecases afterwards
14:22:35 <bauzas> but that should be something we haven't thought supporting
14:23:00 <mriedem> ok
14:23:01 <johnthetubaguy> so the file injection can be safe, using config drive
14:23:05 <mriedem> that's it from me
14:23:29 <johnthetubaguy> but it has all those issues with persistence you mentioned in your ML thread, which makes it trickier
14:24:06 <mriedem> don't we migrate the config drive though?
14:24:14 <mriedem> well,
14:24:15 <johnthetubaguy> not for evacuate
14:24:18 <mriedem> right
14:24:23 <mriedem> was just going to say that
14:24:32 <bauzas> johnthetubaguy: we have a lot of things we can do with boot that we don't check again with any other move operation :)
14:24:35 <mriedem> but, injected files are lost with evacuate regardless
14:24:36 <johnthetubaguy> I think some virt drivers do a recreate, but I am not 100% sure
14:24:55 <bauzas> we *begin* to get the original request, but I don't think persisting the injected file is great
14:25:21 <johnthetubaguy> I am tempted to deprecate it in the API for everyone, or is that too harsh?
14:25:23 <bauzas> unless I'm missing a specific usecase, I don't see what could be the value
14:25:36 <bauzas> argh, I need to bail out
14:25:43 <bauzas> back in 15/20 mins hopefully
14:25:47 <johnthetubaguy> seems like there are lots of ways of getting files in there via user data, that are more scalable
14:25:55 <bauzas> zactly my pinty
14:25:57 <bauzas> point
14:26:09 <bauzas> and you can bootstrap some tool for doing config management
14:26:09 <mriedem> johnthetubaguy: yeah i think we can start working a spec for the deprecation in the api based on the ideas in the ML thread
14:26:23 <johnthetubaguy> mriedem: yeah, thats the best approach
14:26:28 <bauzas> anyway \o
14:26:35 <johnthetubaguy> so it seems no one else is speaking up for any more topics?
14:26:44 <gibi> I have a question about the searchligth related notification bug priority
14:26:58 <johnthetubaguy> did you give them a bug tag right?
14:26:58 <gibi> If I may
14:27:08 <gibi> jeah they are tagged
14:27:11 <gibi> with searchlight
14:27:17 <gibi> but these are not really bugs
14:27:28 <johnthetubaguy> that are new notifications I guess?
14:27:30 <gibi> as they don't talk of a functionality that was ever worked
14:27:42 <gibi> those are additional fields for existing notifications
14:28:10 <gibi> we will add them to the new versioned notifications but I feel that the transformation work has higher priority
14:28:11 <mriedem> i think if we had a few that we wanted to lump into a single specless bp that's fine
14:28:21 <johnthetubaguy> yeah, that works
14:28:25 <mriedem> i agree that this doesn't take priority over the transformation work
14:28:47 <johnthetubaguy> so longer term, they are important due to the cells v2 dependency
14:29:23 <gibi> I can put togheter the bp to sum up the findings in the bug but I cannot promis to work on it in Ocata
14:29:51 <johnthetubaguy> I was going to talk to raj_singh about if any OSIC folks fancied working on those, given the longer term importance
14:30:03 <johnthetubaguy> but I know our place is getting quite full
14:30:10 <johnthetubaguy> s/place/plate
14:30:13 * dansmith rolls in late
14:30:17 <johnthetubaguy> cool, thats a good heads up
14:30:19 <gibi> yeah, transformation work already producing a lot of patches to review
14:30:25 <mriedem> i have to head out too
14:30:28 <johnthetubaguy> any more for any more?
14:30:28 <raj_singh> johnthetubaguy: Some folks already worked on it in Newton, I guess they can spare some cycles now
14:30:34 <mriedem> but we know it's a thing, let's just get a bp for it
14:30:37 <mriedem> and work it if we can
14:30:40 <johnthetubaguy> raj_singh: exactly
14:30:43 <johnthetubaguy> mriedem: +1
14:30:44 <gibi> OK, I will create the BP
14:31:02 <johnthetubaguy> gibi: feel free to pass that my way, and I can help approve that
14:31:08 <johnthetubaguy> cool, any more for any more?
14:31:12 <gibi> johnthetubaguy: OK, thanks
14:31:32 <johnthetubaguy> #action gibi to write up spec less BP for the searchlight bugs
14:31:47 <johnthetubaguy> cool, thanks all
14:31:53 <johnthetubaguy> have 38 mins back
14:32:01 <johnthetubaguy> #endmeeting