21:00:20 <mriedem> #startmeeting nova
21:00:21 <openstack> Meeting started Thu May 12 21:00:20 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:25 <openstack> The meeting name has been set to 'nova'
21:00:32 <mriedem> adrian_otto akuriata alevine alexpilotti aloga andreykurilin anteaya artom auggy
21:00:33 <mriedem> bauzas belliott belmoreira bobball cburgess claudiub danpb dguitarbite _diana_
21:00:33 <mriedem> diana_clarke dims duncant edleafe efried flip214 funzo garyk gcb gjayavelu
21:00:33 <mriedem> irina_pov jaypipes jcookekhugen jgrimm jichen jlvillal jroll kashyap klindgren
21:00:38 <dansmith> o/
21:00:40 <alaski> o/
21:00:40 <takashin> o/
21:00:41 <mriedem> krtaylor lbeliveau lxsli macsz markus_z mdorman med_ mikal mjturek mnestratov
21:00:41 <mriedem> moshele mrda nagyz ndipanov neiljerram nic Nisha PaulMurray raildo rgeragnov
21:00:41 <jroll> ohai
21:00:41 <mriedem> sc68cal scottda sdague sileht sorrison swamireddy thomasem thorst tjones tonyb
21:00:41 <mriedem> tpatil tpatzig xyang rdopiera sarafraj woodster sahid rbradfor junjie gsilvis
21:00:42 <melwitt> o/
21:00:42 <diana_clarke> o/
21:00:44 <auggy> o/
21:00:46 <cdent> o/
21:00:47 <cburgess> 0/
21:00:49 <bauzas> paste flood !
21:00:50 <cburgess> o/
21:00:54 <bauzas> \o
21:00:54 <scottda> hi
21:00:55 <rdopiera> o/
21:00:58 <sc68cal> hello
21:01:04 <raj_singh> o/
21:01:04 <tpatil> Hi
21:01:15 <edleafe> \o
21:01:25 <mriedem> #link meeting agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
21:01:34 <mriedem> #topic release news
21:01:42 <mriedem> #link Newton release schedule: https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
21:01:46 <macsz> O/
21:01:48 <mriedem> #info June 2: newton-1, non-priority spec approval freeze
21:02:00 <mriedem> just a reminder that the next big date is n-1 and non-priority spec approval freeze
21:02:02 <mriedem> on 6/2
21:02:34 <mriedem> we already have a gazillion open specs https://review.openstack.org/#/q/project:openstack/nova-specs+status:open
21:03:05 <gagehugo> o/
21:03:09 <mriedem> so if you're lucky enough to get attention from a core, make sure you reply to any comments super fast
21:03:12 <dansmith> 1.0 gazillion?
21:03:24 <mriedem> 1.23
21:03:28 <dansmith> whoa
21:03:31 <dansmith> that's a lot
21:03:36 <mriedem> any questions about the schedule?
21:03:47 <mriedem> #topic bugs
21:04:03 <mriedem> gate status is okish
21:04:04 <rlrossit> o/
21:04:13 <mriedem> i landed a new test that broke ceph, but nic fixed it quickly
21:04:20 <mriedem> and the revert on the skip of the new test is going through the gate
21:04:23 <claudiub> o/
21:04:52 <mriedem> and we broke ironic's gate, but the fix for that should already be merged by now
21:05:12 <jroll> still stuck in the gate :/
21:05:17 <mriedem> as for 3rd party ci, xenproject ci was failing a lot yesterday, but looked like the same old xenlight thing
21:05:35 <mriedem> i've also noticed some new nfv ci showing up and failing on every run
21:06:08 <mriedem> no other news there though
21:06:21 <mriedem> if you noticed that toggle ci is on by default, it's a bug and infra was fixing it
21:06:39 <mriedem> #topic reminders
21:06:46 <mriedem> #link Newton review focus list: https://etherpad.openstack.org/p/newton-nova-priorities-tracking
21:07:00 <mriedem> if you're a subteam and have stuff in ^ make sure it's up to date
21:07:05 <mriedem> we cleaned up the cells section yesterday
21:07:14 <mriedem> #info We have 55 approved blueprints: https://blueprints.launchpad.net/nova/newton - 6 are completed, 6 have not started, 3 are blocked
21:07:48 <mriedem> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
21:07:59 <mriedem> looks like andrearosa was signed up for exactly 1 day :)
21:08:15 <mriedem> #topic stable branch status
21:08:32 <mriedem> there are open reviews for mitaka and liberty, but otherwise nothing noteworthy
21:08:51 <mriedem> mikal, claudiub and tonyb were cruising through some of those this week
21:09:07 <mriedem> #topic subteam highlights
21:09:13 <bauzas> Liberty is Phase-II by tomorrow, right?
21:09:19 <mriedem> bauzas: is it?
21:09:28 <mriedem> i haven't seen anything official on that
21:09:32 <bauzas> I remember some tonyb's email unless I'm wrong
21:09:47 <mriedem> oh i see it now
21:09:53 <bauzas> http://lists.openstack.org/pipermail/openstack-dev/2016-May/094440.html
21:10:10 <bauzas> all hail our stable PTL
21:10:15 <mriedem> "I'd like all stable teams to transition to Phase II support "Critical bugfixes and security patches only" as of 2016-05-15."
21:10:29 <mriedem> For the record the final EOL date for Liberty is 2016-11-17
21:10:33 <jlvillal> o/
21:10:50 <mriedem> the final kilo release was cut this week too
21:10:52 <bauzas> okay, not tomorrow, Monday :)
21:10:56 <mriedem> so the stable/kilo branch will be gone soon
21:11:10 <mriedem> so back to subteam stuff
21:11:15 <mriedem> alaski: cells v2 highlights?
21:11:27 <alaski> there's a lot to review, could use eyes there
21:11:37 <alaski> and there's a lot to migrate from cell db to api db
21:11:50 <alaski> but it's all pretty much in motion
21:12:08 <mriedem> k
21:12:25 <mriedem> jaypipes: cdent: edleafe: scheduler highlights?
21:12:34 <mriedem> i have some notes in the agenda if you're shy
21:12:37 * cdent looks around
21:12:41 <mriedem> Continuing review on generic-resource-pools spec: https://review.openstack.org/#/c/300176/
21:12:43 <edleafe> lotsa specs getting churned
21:12:48 <mriedem> Need to move inventories tables to API DB before we can migrate  compute_node data to allocations tables (or do generic-resource-pools).
21:12:58 <cdent> jaypipes and dansmith figured out the db move stuff, but I'm not actually sure what the decision was
21:13:12 <edleafe> yeah, that will be a surprise
21:13:29 <dansmith> um
21:13:41 <edleafe> oh, forgot the smiley
21:13:42 <dansmith> why a surprise? jaypipes pasted bits in the channel even
21:13:50 <mriedem> so, jaypipes signed up for that the other day
21:14:08 <cdent> Yingxin provided some good feedback on the object structure in generic-resource-pools which might shake things up a bit
21:14:45 <mriedem> something something backref
21:14:46 <mriedem> i saw that
21:14:54 <mriedem> and the placement rest api is in flux
21:15:02 <bauzas> the spec you mean
21:15:09 <mriedem> so ftr i'm waiting to review the generic-resource-pools spec until that's sorted out
21:15:16 <mriedem> bauzas: yes in the spec
21:15:18 <bauzas> I saw jay -1d his spec :)
21:15:33 <mriedem> anyway, point is, inventories to api db is priority #1
21:15:35 <bauzas> cdent: you're now aligned with him ?
21:15:37 <cdent> mriedem: it would probably be better to review sooner than later as waiting until it is "ready" is entirely contrary to the point of review, no?
21:15:40 <mriedem> dansmith and jaypipes are on the same page there
21:15:50 <mriedem> cdent: i was ready a few days ago
21:15:54 <mriedem> but then the rest api blew up
21:16:01 <mriedem> so i'm not getting in the middle of that really
21:16:14 <cdent> you don't care or you don't have an opinion?
21:16:29 <mriedem> i will defer to you guys who have a stronger opinion about the rest api than me
21:16:31 <bauzas> I thought we were providing a summary :)
21:16:38 <cdent> bauzas: heh
21:16:46 <cdent> anyway, yeah, lots of action in the last 24 hours
21:16:51 <cdent> it's a bit bursty
21:17:02 <bauzas> it's darn hard to follow indeed
21:17:10 <mriedem> moving on?
21:17:10 <bauzas> but that's life
21:17:15 <bauzas> mriedem: hell yeah
21:17:22 <mriedem> live migration
21:17:33 <mriedem> libvirt-instance-storage spec is approved (refactor/cleanup work in the libvirt imagebackend code): https://review.openstack.org/#/c/302117/
21:17:42 <mriedem> mdbooth: has a big refactor series for ^
21:17:50 <mriedem> looks like a bunch of it is in merge conflict now
21:17:58 <dansmith> with the rbd fix I bet
21:17:58 <mriedem> * Working on adding test coverage for LVM and Raw image backends for testing ^
21:18:03 <mriedem> dansmith: maybe
21:18:17 <mriedem> i'm playing with an lvm job https://review.openstack.org/#/c/314744/
21:18:27 <mriedem> resize is not happy with lvm
21:18:36 <mriedem> cfriesen was going to push some patches to fix that
21:18:37 <mriedem> so we'll see
21:18:48 <mriedem> else we just skip the tests, but testing resize/migrate with these different image backends was kind of the point
21:19:18 <mriedem> moving on
21:19:20 <mriedem> api
21:19:23 <mriedem> * api-ref sprint: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094872.html
21:19:28 <mriedem> sdague: anything else for api?
21:19:46 <mriedem> #help api-ref sprint api-ref sprint: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094872.html
21:20:05 <mriedem> #link open api-ref reviews https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
21:20:13 <auggy> the api meeting this week was api-ref focused with the intention to focus on api related spec review next week
21:20:21 <mriedem> yup
21:20:29 <mriedem> the api-ref reviews aren't too hard, just time consuming and draining
21:20:31 <mriedem> :)
21:20:48 <bauzas> that sounds a continous effort
21:20:53 <auggy> also i'm working on a more user friendly report on what still needs to be done
21:20:58 <mriedem> well http://burndown.dague.org/
21:21:09 <mriedem> there has been decent progress this week
21:21:40 <mriedem> thanks to everyone helping out on that
21:21:45 <mriedem> #topic stuck reviews
21:21:55 <mriedem> #link https://review.openstack.org/#/c/295595/ Re-Propose Expose quiesce/unquiesce API
21:22:11 <mriedem> so this was a spec to expose quiescing an instance
21:22:18 <mriedem> re-proposed from mitaka (previously approved)
21:22:27 <mriedem> however, dansmith has reservations
21:22:43 <mriedem> the reply to those was, something, enterprise, application, needed
21:22:50 <dansmith> yeah, johnthetubaguy said he didn't really like it either, but it was previously approved
21:23:11 <dansmith> personally I don't think it's a good idea, but I -1ed to advise, so if others want it then they should put it in
21:23:21 <dansmith> I haven't circled back to see the reply,
21:23:24 <dansmith> but ... sounds convincing
21:23:51 <mriedem> "application level consistency snapshot is critical for disaster recovery of an application"
21:24:07 <dansmith> for anyone that doesn't know,
21:24:24 <dansmith> this is wanting to be able to snapshot multiple instances at the same time
21:24:37 <melwitt> I thought it already quiesces before a snapshot. oh
21:24:49 <dansmith> which requires client software to quiesce and freeze them from the api side, one at a time, in the right order, do the thing, then unfreeze in the right order
21:25:07 <dansmith> more state modeling for us, new api semantics for instances currently frozen, etc
21:25:18 <dansmith> I think the use case is pretty weak,
21:25:31 <dansmith> when it could all be done at the *actual* application layer if desired
21:26:22 <mriedem> ok, i'll have to read back through it from the start
21:27:04 <mriedem> oh i see the blueprint says "In NFV scenario, a VNF (telecom application) often is consisted of a group of VMs."
21:27:10 <bauzas> yeah, I just wonder what the benefit for Nova is
21:27:12 <mriedem> of course...
21:27:24 <mriedem> so quiesce + volume multi-attach, it's going to be great
21:27:25 <dansmith> yeah, so for something that is highly network-dependent,
21:27:44 <dansmith> we're going to quiesce and freeze the first one, then do the next, the next, then snapshot, then undo that in reverse order
21:27:52 <dansmith> I'm sure the telecom user will just wait
21:28:08 <dansmith> seems dubious to me
21:28:09 <dansmith> anyway,
21:28:13 <dansmith> that's all.. we should move on
21:28:22 <dansmith> just .. review that for real and don't rubber stamp it, IMHO
21:28:34 <dansmith> I was -1 on it the first time around too, but.. alas
21:28:55 <mriedem> i need to look up the original mitaka review
21:29:21 <mriedem> #topic open discussion
21:29:30 <mriedem> tpatil: Set migration status to 'error' instead of 'failed' during live-migration
21:29:36 <tpatil> we have sent an email to the operators mailing list for getting their opinion about this particular fix
21:29:49 <tpatil> #link http://lists.openstack.org/pipermail/openstack-operators/2016-May/010353.html
21:29:54 <mriedem> the response was 'meh' :)
21:30:04 <tpatil> so far, we have got 2+ve and 0 -ve responses.
21:30:17 <mriedem> yeah, basically, they don't care b/c it's not instance status
21:30:19 <mriedem> it's migration status
21:30:22 <mriedem> which they aren't using from the api yet
21:30:32 <tpatil> right
21:30:33 <tpatil> IMO, there are no side effects if migration status is changed from failed to error for live migration operation.
21:30:37 <mriedem> but cold + live migration status being consistent is a net good
21:30:50 <tpatil> right
21:30:56 <tpatil> I request core reviewers to take this mailing thread discussion into account and decide the future of our proposed fix.
21:31:14 <mriedem> i propose that we split it in half and give one half to each submitter
21:31:43 <mriedem> yeah i think we're fine with moving forward on it
21:31:57 * mriedem notes there are no old testament buffs in the room
21:32:03 <dansmith> i got it
21:32:07 <dansmith> just didn't approve
21:32:26 <mriedem> ok, anything else for open discussion?
21:32:33 <melwitt> I got it too, but only because you've said it before :)
21:32:47 <mriedem> i wake my daughter up in the morning with that saying
21:32:51 <dansmith> melwitt: learning the bible from mriedem and nova irc since 2016
21:32:53 <melwitt> lol
21:33:10 <mriedem> alright, let's end it
21:33:12 <mriedem> thanks everyone
21:33:15 <mriedem> #endmeeting