21:00:10 <mriedem> #startmeeting nova
21:00:10 <openstack> Meeting started Thu Aug 13 21:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:13 <openstack> The meeting name has been set to 'nova'
21:00:17 <alaski> o/
21:00:20 <dansmith> o-
21:00:21 <mriedem> mikal tjones cburgess jgrimm adrian_otto funzo mjturek jcookekhugen irina_pov krtaylor danpb alexpilotti flip214 jaypipes garyk edleafe dims moshele anteaya Nisha sileht claudiub lxsli neiljerram markus_z swamireddy alevine tonyb andreykurilin ndipanov sc68cal akuriata artom jlvillal mnestratov kashyap aloga rgeragnov bauzas xyang tpatil med_ nic scottda nagyz dannywilson - please all set calendar reminders
21:00:22 <mriedem> lazy bones
21:00:24 <rlrossit> o/
21:00:24 <n0ano> o/
21:00:29 <jaypipes> o.../
21:00:32 <nagyz> o/
21:00:34 <scottda> hi
21:00:37 <melwitt> o/
21:00:38 <dannywilson> hello
21:00:40 <med_> \o
21:00:41 <tjones> hi
21:00:41 <claudiub> o/
21:00:46 <edleafe> o/
21:00:50 <cburgess> here
21:00:51 <mriedem> https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
21:00:54 <cburgess> o/
21:00:58 <cburgess> or whatever we say now
21:00:59 <mriedem> #topic releasestatus
21:01:15 <mriedem> alright, there is a thing in the agenda saying feature proposal freeze is 8/18
21:01:20 <mriedem> which seems odd to me
21:01:23 <mriedem> we're already past feature freeze
21:01:46 <mriedem> also, FFE requests were processed last week in https://etherpad.openstack.org/p/liberty-nova-non-priority-feature-freeze
21:01:49 <mriedem> so thats probably old news
21:02:07 <mriedem> schedule https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Dates_overview
21:02:17 <mriedem> liberty-3 is 9/1
21:02:32 <mriedem> i think after that is stringfreeze
21:02:43 <mriedem> so get your user facing error message changes in before then
21:02:45 <mriedem> or else
21:02:55 <mriedem> questions?
21:03:03 <mriedem> #topic bugs
21:03:07 <mriedem> the gate is gr8
21:03:16 <mriedem> well, logstash is behind by 13 hours so we don't know, but seems ok
21:03:27 <mriedem> i don't see any critical bugs
21:03:40 <mriedem> stable branches are coolio
21:03:42 <mriedem> at least for nova
21:03:45 <mriedem> some other projects are borked
21:03:46 <mriedem> but meh
21:03:54 <mriedem> questions?
21:04:04 * edleafe thinks this will be the fastest meeting ever
21:04:06 <mriedem> #topic reviewreminders
21:04:10 <mriedem> #link https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
21:04:15 <mriedem> review stuff in there
21:04:25 <mriedem> i actually dabbled in some of the sub-team stuff earlier in the week
21:04:27 <mriedem> for hyper-v bugs
21:04:33 * n0ano wonders if we can have a meeting where mriedem is the only talker
21:04:37 <claudiub> ty :)
21:04:55 <mriedem> john was asking sub-teams to keep high priority bugs in there
21:05:07 <mriedem> i think garyk was going to do that for vmware
21:05:15 <mriedem> #link https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
21:05:22 <mriedem> summit actions - that all seems old hat
21:05:33 <edleafe> n0ano: sorry, claudiub ruined it. :)
21:05:36 <mriedem> if you still have summit actions and haven't done them, you're a terrible person
21:05:51 <mriedem> questions?
21:05:58 <mriedem> #topic stuckreviews
21:06:07 <mriedem> there are two
21:06:08 <mriedem> 1. https://review.openstack.org/#/c/206576/
21:06:08 <dansmith> once again,
21:06:10 <dansmith> these don't seem stuck
21:06:23 <mriedem> nagyz: around?
21:06:25 <nagyz> yes
21:06:35 <mriedem> encrypted rbd volumes, go
21:06:39 <nagyz> they are stuck in a sense that there is disagreement at least for that.
21:06:56 <nagyz> the original code change changes how qemu handles ceph disks
21:07:11 <nagyz> instead of using the native qemu driver for encryption we must first attach it to the hypervisor.
21:07:27 <nagyz> thus some people think this should merit a spec, some don't
21:07:30 <nagyz> thus the disagreement
21:07:39 <dansmith> it doesn't matter about the spec
21:07:42 <dansmith> it matters if it's a feature or a bug
21:07:44 <nagyz> the original meat of the patch is around 10 lines, but due to the volume driver cleanup it has the tests refactored
21:07:51 <dansmith> and I agree with danpb, that it's a featuer, spec or not
21:07:52 <nagyz> it's a bug
21:08:15 <dansmith> it adds a new driver thing, a new entrypoint, etc -> feature, IMHO
21:08:32 <dansmith> titled "add $foo support" -> feature, IMHO
21:08:45 <nagyz> I can rename it to "fix rbd mapping for encryptors" ;)
21:09:02 <dansmith> also depends on an unmerged devstack change
21:09:08 <mriedem> for context, the bug was really that the encrypted cinder volumes test was passing in jenkins for ceph, when in fact they weren't encrypted
21:09:10 <dansmith> with no traffic all month
21:09:22 <mriedem> the nova and devstack change are intertwined
21:09:24 <nagyz> dansmith, we cannot merge in the devstack change until this patch is in
21:09:33 <nagyz> otherwise gate gets b0rked
21:09:35 <dansmith> well, you depends-on the devstack change
21:09:40 <mriedem> i believe we fixed the bug by failing fast that stuff that's not encrypted will fail
21:09:42 <dansmith> which means you can't land nova until the devstack one
21:09:43 <nagyz> so we can run the ceph tests
21:09:50 <mriedem> if asked to be created from an encrypted volume type in cinder
21:09:53 <nagyz> it's a bit... strange. the depends-on doesn't work the other way around
21:10:06 <dansmith> nagyz: regardless, the way you have it, it won't merge
21:10:09 <nagyz> mriedem, right, and currently the ceph encrypted tests are just skipped
21:10:36 <nagyz> dansmith, correct, but this was necessary in order to run the patch on the gate. the plan was to remove the depends-on once we agree that it can be merged
21:10:39 <mriedem> devstack doesn't run the ceph job,
21:10:42 <nagyz> and only after merge in the devstack change
21:10:46 <mriedem> that's why the depends-on is the way it is
21:10:50 <dansmith> okay
21:11:04 <mriedem> i did confirm that with the change, the encrypted volumes test is passing
21:11:09 <dansmith> shall I throw my -2 on it to document?
21:11:11 <mriedem> in the ceph job with that devstack change
21:11:23 <nagyz> dansmith, without the patch basically nova encryption is pretty useless
21:11:34 <mriedem> for rbd
21:11:39 <mriedem> and many other volume drivers
21:11:41 <nagyz> the only thing it works for is iSCSI
21:11:44 <mriedem> fc and iscsi work
21:11:45 <nagyz> at the moment
21:11:47 <dansmith> lots of features didn't make it
21:11:48 <nagyz> not sure about FC
21:12:09 <nagyz> dansmith, it's really about making the rbd volume accessible to the encryptors
21:12:27 <dansmith> this patch won't fix FC if it doesn't already work, AFAICT
21:12:40 <dansmith> anyway, I'll comment on the patch
21:12:42 <nagyz> correct, just saying that the ONLY driver I'm pretty sure it works now is iSCSI
21:12:45 <mriedem> fibrechannel encryption works
21:12:49 <nagyz> ok, then FC too.
21:12:51 <mriedem> after i fixed compute.filters
21:13:02 <mriedem> fc == fibrechannel so that we're on the same page :)
21:13:16 <nagyz> according to the survey, ceph is ~50% of the cinder usage
21:13:20 <nagyz> as underlying storage
21:13:51 <cburgess> Not sure if it matters but I know a number of operators who have wanted encryption so it would be a "nice to have" for some of us.
21:13:54 <mriedem> yeah, but we also didn't approve nic's snapshot improvement after FF
21:14:07 <nic> Nope
21:14:20 <cburgess> That one too but... yeah... FF
21:14:22 <nagyz> cburgess, it should matter. hopefully.
21:14:33 <nagyz> without the flattening, snapshotting still works.
21:14:37 <nagyz> without this patch encryption with ceph doesn't work
21:14:59 <mriedem> i think danpb had some other design concerns in the change
21:15:14 <cburgess> Works is relative... as long as you have as much disk available locally to hold the snapshot as you do in CEPH then you are golden. So for all practical use cases it doesn't work.
21:15:15 <mriedem> so those would at least have to be reconciled before i think we could talk about allowing this into liberty
21:15:34 <mriedem> we need to move on
21:15:36 <nagyz> mriedem, and I'm happy to work on the patch to shape it into whatever gets acceptable.
21:15:43 <nagyz> if there's a change we can get it into L
21:16:08 <mriedem> nagyz: so you have the todo to talk to danpb about it i guess, but if he's not in favor then i think it's a dead end
21:16:17 <mriedem> for liberty i mean
21:16:23 <mriedem> moving on
21:16:25 <nagyz> he categorically denied support for L
21:16:25 <nagyz> ok.
21:16:29 <mriedem> dannywilson: https://review.openstack.org/#/c/205726/ - discard support, go
21:16:40 <dannywilson> I updated the review with more detail in commit message
21:16:41 <mriedem> danpb was +2 on ^
21:16:55 <dannywilson> and added version check as well for min qemu version
21:16:56 <mriedem> there was a related cinder change that made L to set the discard flag
21:17:10 <mriedem> so the question is, do we allow this in nova in liberty to use what cinder is providing
21:17:42 <mriedem> it's still a bp imo
21:17:46 <mriedem> doesn't need a spec
21:17:48 <mriedem> there was a cinder spec
21:18:02 <mriedem> given it's a bp and given precedent on not allowing bp's in after the freeze,
21:18:06 <mriedem> i'm inclined to tow that line
21:18:29 <dannywilson> too late for FFE?  thingee and jgriffith were for getting it in
21:18:40 <mriedem> FFE deadline passed a couple of week sago
21:18:52 <dansmith> I think it's squarely a feature
21:18:56 <dannywilson> gotcha
21:19:17 <mriedem> so it sucks,
21:19:18 <dansmith> it's a little more in the main path and smaller, but we have to draw the line somewhere and this doesn't seem to fit any of the guidelines for breaking rules
21:19:33 <dansmith> ...he says as if there are guidelines
21:19:39 <mriedem> yeah, we have to be equal opportunity offenders imo
21:19:44 <dansmith> yup
21:20:03 <dannywilson> understood, thanks for talking about it and I will get it in for M
21:20:09 <jgriffith> bummer... thanks anyway
21:20:09 <mriedem> cool
21:20:22 <mriedem> any more stuck reviews?
21:20:23 <dansmith> dannywilson: should be super trivial for early in M.. feel free to ping me
21:20:23 <mriedem> no?
21:20:24 <mriedem> ok
21:20:31 <mriedem> #topic opendiscussion
21:20:32 <dannywilson> dansmith: thanks
21:20:34 <mriedem> john had this https://review.openstack.org/#/c/198622/6/specs/liberty/approved/add-vif-net-id-in-vif-list.rst,cm
21:20:41 <mriedem> "its a spec for an API bug fix, about the v2 compatibility mode being broken, seems we should merge this one"
21:20:51 <alaski> I asked him to add that one
21:21:01 <alaski> it's an API change, but it's also a regression
21:21:10 <mriedem> john is +2 on it, sdague and kenichi are +1
21:21:21 <dansmith> this is the thing we talked about at midcycle, right?
21:21:23 <mriedem> alaski: so i guess it's a spec b/c we've said spec for all api changes?
21:21:28 <alaski> mriedem: right
21:21:29 <dansmith> I thought there was more to be done to get it right.. was that done?
21:21:43 <mriedem> "Thanks for working on hard on finding a good compromise here. I think this looks good."
21:21:45 <mriedem> looks like it
21:21:48 <dansmith> oh, no, this is not that, nevermind
21:22:19 <mriedem> #link https://bugs.launchpad.net/nova/+bug/1470690
21:22:19 <openstack> Launchpad bug 1470690 in OpenStack Compute (nova) "No 'OS-EXT-VIF-NET' extension in v2.1" [High,In progress] - Assigned to Ghanshyam Mann (ghanshyammann)
21:22:23 <mriedem> that's the bug fwiw
21:22:28 <uvirtbot> Launchpad bug 1470690 in nova "No 'OS-EXT-VIF-NET' extension in v2.1" [High,In progress]
21:22:29 <uvirtbot> Launchpad bug 1470690 in nova "No 'OS-EXT-VIF-NET' extension in v2.1" [High,In progress] https://launchpad.net/bugs/1470690
21:22:29 <alaski> I'm fine moving forward on this because it is a regression, but it is well past the deadline
21:22:53 <mriedem> yeah, this seems like an exceptional case however
21:23:07 <dansmith> yeah
21:23:11 <mriedem> and this isn't a feature add
21:23:25 <mriedem> the spec appears to be purely for process
21:23:29 <mriedem> so seems fine to me
21:23:30 <dansmith> yep, just docs
21:23:32 <alaski> yep
21:23:37 <alaski> okay, I'll approve then
21:23:51 <mriedem> ok
21:23:55 <alaski> thanks
21:23:56 <mriedem> any other open discussion?
21:24:05 <tonyb> mriedem: I added https://review.openstack.org/#/c/127427/
21:24:08 <melwitt> do the tempest jobs catch these kind of regressions?
21:24:27 <mriedem> melwitt: i guess not in this case?
21:24:37 <dansmith> melwitt: should != do
21:24:43 <mriedem> melwitt: we should dig into that though since we have a v2.1 job
21:24:45 <alaski> melwitt: not if it's unused, which this must be for tempest
21:24:50 <mriedem> i know we don't have upper bounds testing on v2.1 yet
21:25:01 <dansmith> we should also catch this with api samples, right?
21:25:02 <mriedem> yeah, tempest doesn't have great n-net specific api testing
21:25:15 <melwitt> okay. was just thinking about if there might be more of these and how we can catch them
21:25:30 <mriedem> there is a QA meetup mid september that kenich is going to, and i'm trying to go to
21:25:41 <mriedem> so we could add it there as a thing to cover - i know microversoin testing for nova will be covered
21:25:51 <mriedem> *ken'ichi
21:26:02 <mriedem> tonyb: https://review.openstack.org/#/c/127427/ - go
21:26:12 <tonyb> mriedem: It's not mine
21:26:17 <mriedem> yeah
21:26:20 <mriedem> tjones: perma rebase
21:26:24 <tonyb> mriedem: but it's one that need to rebased very often
21:26:31 <mriedem> so it's a request for review
21:26:35 <tonyb> just wanted to ask for some reviws from @core
21:26:47 <tonyb> mriedem: Yeah
21:27:28 <mriedem> alright
21:27:36 <dansmith> done?
21:27:38 <mriedem> anything else for open discussion?
21:27:47 <mriedem> nope
21:27:52 <dansmith> move to adjourn with extreme prejudice
21:27:52 <mriedem> ok, thanks, fin.
21:27:55 <mriedem> #endmeeting