15:59:50 <smcginnis> #startmeeting cinder
15:59:50 <openstack> Meeting started Wed Nov 25 15:59:50 2015 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:53 <openstack> The meeting name has been set to 'cinder'
16:00:10 <geguileo> Hi!
16:00:12 <thangp_> o/
16:00:12 <ntpttr> Hi o/
16:00:12 <jseiler> hi
16:00:15 <kaisers> Hi
16:00:17 <dulek> hello
16:00:18 <thingee> o/
16:00:19 <patrickeast> Hi
16:00:27 <smcginnis> Hey everyone.
16:00:48 <xyang> hi
16:00:52 <tbarron> hi
16:01:50 <smcginnis> #Announcements
16:01:59 <smcginnis> #topic Announcements
16:02:04 <smcginnis> Sorry, slow today. :)
16:02:17 <smcginnis> Just want to point out M-1 is coming up quick.
16:02:24 <bswartz> hi
16:02:43 <smcginnis> Based on the new deadlines, that's not a major point, but good to realize we are already that far into the cycle.
16:03:02 <dulek> #link https://launchpad.net/cinder/+milestone/mitaka-1
16:03:30 <smcginnis> Pretty decent list already there. :)
16:03:34 <smcginnis> #topic Bug Status
16:03:53 <smcginnis> Bugs are looking good. The numbers have actually gone down.
16:04:05 <smcginnis> Thanks to those spending some time cleaning that up.
16:04:19 <smcginnis> I've seen a lot of good updates there.
16:04:46 <smcginnis> It looks like a good number of them could just be from the linkage not working and not changing the bug to Fix Committed when patches have gone through.
16:04:46 <e0ne> hi
16:04:55 <smcginnis> My hope is a lot of them can just be closed out at this point.
16:05:26 <smcginnis> #info Cinder: 473 bugs, CinderClient 43 bugs, OS-Brick: 15 bugs
16:05:37 <smcginnis> mtanino: You've done quite a few. Thanks!
16:05:50 <smcginnis> Still several nova volume related bugs.
16:05:54 <mtanino> hello?
16:06:09 <smcginnis> If anyone can take a look through the link and see if we can provide any input.
16:06:22 <smcginnis> mtanino: Hi! Just thanking you. Nothing to worry about. :)
16:06:32 <mtanino> oops, meeting. sure :)
16:06:40 <smcginnis> #link https://bugs.launchpad.net/nova/+bugs?field.status:list=NEW&field.tag=volumes
16:07:13 <smcginnis> OK, enough boring administrative stuff. :)
16:07:24 <smcginnis> #topic Copy encryptors from Nova to os-brick
16:07:31 <smcginnis> lixiaoy1: Hi
16:07:58 <lixiaoy1> hi
16:08:09 <DuncanT> For reference, I added this to the nova meeting agenda too
16:08:15 <DuncanT> Meeting is tomorrow
16:08:27 <smcginnis> DuncanT: Awesome, thanks. I'll try to be there too.
16:08:54 <lixiaoy1> I am concerned how to move forward. As Nova doesn't want cinder to decrypt volumes.
16:09:35 <smcginnis> lixiaoy1: So if I remember right, some of our use cases are being questioned, but there is general agreement that copy volume to image will need us to be able to decrypt.
16:09:38 <e0ne> it's a problem in case, if we'll implement attach w/o nova
16:09:44 <smcginnis> lixiaoy1: Is that right?
16:09:58 <smcginnis> e0ne: Oh yea, that too.
16:10:18 <bswartz> nova is meeting tomorrow?
16:10:36 <bswartz> tomorrow is a US holiday
16:10:39 <lixiaoy1> two cases: 1. create encrypted voluem from image, 2. retype volume with different encryptions. for example, retype unencrypted volume to encrypted
16:10:39 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079964.html
16:10:47 <e0ne> DuncanT: I don't see link to nova meeting in our agenda
16:10:55 <smcginnis> bswartz: Oh yeah, good point.
16:11:05 <xyang> what about this one?  https://review.openstack.org/#/c/247577/  Integrate Castellan for Key Management
16:11:05 <smcginnis> #link https://review.openstack.org/#/c/247372/
16:11:12 <smcginnis> #link https://review.openstack.org/#/c/248593/
16:11:16 <DuncanT> bswartz: November 26th 2015 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20151126T140000
16:11:37 <DuncanT> bswartz: At least according to https://wiki.openstack.org/wiki/Meetings/Nova
16:11:39 <lixiaoy1> xyang: this is just move key manager to common library. keymgr under cinder
16:11:43 <bswartz> interesting -- I bet many US-based people will be absent
16:11:54 <smcginnis> Well, John is in the UK, so maybe they don't care.
16:12:04 <kaisers> I think john still wanted to run the Nova meeting, there was a mail on the list today
16:12:17 <kaisers> sry, still digging for the link
16:13:14 <DuncanT> think putting the patch up to move the existing nova code into brick is worth posting. There's a great deal of designing of new security models going on, but not a lot of solving existing problems, so I suspect nova will move to brick code without too much trouble
16:13:28 <lixiaoy1> xyang: https://github.com/openstack/cinder/tree/master/cinder/keymgr
16:13:41 <xyang> lixiaoy1: thanks
16:14:08 <smcginnis> So, not to be a jerk, but nova can't block us adding it to os-brick and cinder. Whether they want to use it or not is up to them.
16:14:21 <smcginnis> Definitely not a stance I want to take, but that's the reality.
16:14:31 <smcginnis> I think we've clearly identified the need for it.
16:15:05 <DuncanT> smcginnis: +1
16:15:18 <kaisers> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080388.html
16:15:22 <smcginnis> And saying it's a security issue when anyone can go out to the nova source and get the code to decrypt a volume anyway kind of makes it an invalid argument IMO.
16:15:30 <DuncanT> smcginnis: I think once the code is in brick, the patch to change nova to use that will go in - it doesn't actually change anything for them
16:15:35 <lixiaoy1> smcginnis: I agree. I think we can't leave cinder things to nova. That is back to nova-volume, and it blocks our future goal independent SDS
16:15:58 <smcginnis> DuncanT: I hope so.
16:16:36 <smcginnis> Any other thoughts on this from anyone else?
16:17:05 <smcginnis> So safe to say lixiaoy1 can move ahead with the work?
16:17:10 <tbarron> +1
16:17:26 <bswartz> yeah I want to offer a general +1 for that approach
16:17:48 <bswartz> the discussion on the ML made me a bit worried, but perhaps that's been resolved
16:18:06 <smcginnis> Great. lixiaoy1, do you need any other input to be able to proceed?
16:18:30 <smcginnis> bswartz: Maybe not resolved, but close enough. ;)
16:18:35 <lixiaoy1> smcginnis: thanks, that is enough.
16:18:58 <geguileo> smcginnis: +1
16:19:31 <smcginnis> lixiaoy1: Great. Thanks for pushing on with this. The patches and ML posts have been good to get the discussion out there.
16:19:55 <smcginnis> #topic CI Documentation
16:20:02 <smcginnis> #link https://wiki.openstack.org/wiki/Documentation/VendorDrivers
16:20:09 <smcginnis> I've added a column to the CI table.
16:20:23 <smcginnis> I have three points for bringing this up.
16:20:51 <smcginnis> First, we haven't really standardized on a recheck trigger for everyone, so there is confusion on how to do that when we see a CI failing and want result.
16:21:13 <smcginnis> If everyone operating a CI can update this table with the string(s) that will run there's, we at least have a reference then.
16:21:20 <dulek> I like DIE DIE DIE, can we build on that?
16:21:22 <mtanino> it's nice.
16:21:33 <smcginnis> Ideally I would like to move to a common pattern, but this is a start.
16:21:41 <smcginnis> dulek: Yep. :)
16:21:53 <smcginnis> Second point is just to remind everyone that this page exists.
16:22:12 <smcginnis> So new driver submitters and current operators, please make sure this is up to date with your info.
16:22:32 <thingee> smcginnis: not to sidetrack, but what are the reasons for duplicating the work here in this wiki with driverlog.
16:22:40 <smcginnis> I think we've had once or twice where the operator contact changed but this page still referenced someone who was no longer with the company.
16:23:09 <smcginnis> thingee: Easy reference and update I think. But I had wondered the same thing at the time.
16:23:22 <smcginnis> I think for a little while there we had 3-4 places duplicating the same info.
16:23:35 <smcginnis> And DuncanT did some work to try to make this automated.
16:23:56 <thingee> With Cinder getting more serious in defcore, I think it's important for us to be more focused with driverlog
16:24:03 <thingee> since it'll be the source of truth
16:24:08 <xyang> thingee: can you add a new column in driverlog for the recheck command?
16:24:10 <thingee> according to the market place
16:24:56 <smcginnis> thingee: Just to make sure, you're talking about this one? http://stackalytics.com/report/driverlog?project_id=openstack%2Fcinder
16:25:48 <thingee> smcginnis: I have no affiliation with stackalytics nor trust it.
16:25:53 <thingee> smcginnis: I'm talking about https://github.com/openstack/driverlog/blob/master/etc/default_data.json
16:25:55 <smcginnis> thingee: :)
16:26:09 <smcginnis> So there's at least three places to look. :[
16:26:30 <thingee> xyang: there is a ci field. Not familiar with it though https://github.com/openstack/driverlog/blob/master/etc/default_data.json#L164
16:26:30 <smcginnis> But I think stackalytics pulls form the driverlog.
16:26:54 <patrickeast> yea I thought those were one in the same
16:27:02 <smcginnis> But I see driverlog and this wiki as slightly different.
16:27:19 <smcginnis> There are companies where the contact for the driver is different than the contact for the CI.
16:27:40 <asselin> fyi stackanalytics will soon be hosted/supported directly by openstack.org
16:27:44 <smcginnis> So in that respect, I'm fine keeping two different places.
16:27:47 <xyang> smcginnis: because they were updated by different people:)
16:28:12 <kaisers> IIRC a ci should always post a link to it's wiki page when commenting on a change. Shouldn't the recheck command be documented in there? (see http://docs.openstack.org/infra/system-config/third_party.html#requirements)
16:28:24 <xyang> smcginnis: the wiki was probably set up initially by the doc team and now it was updated by others
16:28:44 <smcginnis> kaisers: True, that is listed as a requirement.
16:29:01 <smcginnis> I don't think it's widely followed though currently.
16:29:07 <kaisers> Advantage is that that link should normally be posted with each comment of the CI
16:29:11 <kaisers> smcginnis: ok :)
16:29:29 <smcginnis> Not that they shouldn't. :)
16:30:22 <kaisers> smcginnis: shoudl not? "All comments from your CI system must contain a link to the wiki page for your CI system."
16:30:28 <smcginnis> The official third party documentation does point to here: https://wiki.openstack.org/wiki/ThirdPartySystems
16:30:37 <kaisers> smcginnis: oops :)
16:30:42 <smcginnis> kaisers: Not saying they shouldn't. Just pointing out they currently don't.
16:30:57 <patrickeast> maybe we should enforce it?
16:30:57 <kaisers> smcginnis: ack
16:31:06 <smcginnis> Yeah, we probably should.
16:31:18 <smcginnis> CI does need some attention for sure.
16:31:47 <smcginnis> So how about this. I'll put a note in the first wiki page pointing everyone to go to https://wiki.openstack.org/wiki/ThirdPartySystems
16:32:04 <smcginnis> And we start making sure at least that one has all the info we need.
16:32:11 <smcginnis> And start deprecating the other one.
16:32:23 <smcginnis> And maybe driverlog can be updated to point to there to get more details at some point.
16:32:52 <smcginnis> #action CI maintainers to update CI info with recheck trigger details.
16:32:55 <smcginnis> #link https://wiki.openstack.org/wiki/ThirdPartySystems
16:33:28 <smcginnis> Make sense?
16:33:33 <kaisers> +1
16:33:37 <patrickeast> sounds good to me
16:33:47 <kmartin> +1
16:34:15 <smcginnis> Good. Then hopefully we can get rid of one of the multiple locations.
16:34:32 <smcginnis> I'll update the Cinder wiki that leads to the old one.
16:34:45 <smcginnis> #action smcginnis to update third party CI links on Cinder wiki.
16:35:24 <smcginnis> #topic Open discussion
16:35:31 <smcginnis> The floor is open...
16:36:08 <tbarron> we've set up a block of rooms for the January mid-cycle
16:36:18 <smcginnis> Sorry!
16:36:24 <tbarron> you can reserve via this link:
16:36:26 <dulek> tbarron: Any deadline for booking?
16:36:27 <smcginnis> I meant to cover that in announcements!
16:36:35 <tbarron> http://hiltongardeninn.hilton.com/en/gi/groups/personalized/R/RDUSPGI-NET-20160125/index.jhtml
16:36:42 <smcginnis> tbarron: Thank you for arranging that.
16:36:42 <tbarron> deadline is January 4
16:37:10 <tbarron> after that the negotiated rate of $130/night may not be available.
16:37:50 <smcginnis> Also reminder for folks to add your name to the etherpad if you are planning on attening.
16:38:00 <smcginnis> Physical or virtual, just so we know what to expect.
16:38:02 <smcginnis> #link https://etherpad.openstack.org/p/mitaka-cinder-midcycle
16:38:51 <tbarron> Currently they are blocking off 30 rooms, but we can adjust the quota if it starts filling up :-)
16:38:51 <smcginnis> And thank you Pure and IBM for signing up to host dinners a couple of the nights.
16:40:27 <smcginnis> Any other topics?
16:40:57 <ntpttr> so I recently started contributing and haven't been around for a midcycle, what does virtually attending look like?
16:41:09 <tbarron> dulek: and anyone coming from abroad: I think you can reserve and then cancel later (up to one day prior) withoout penalty.
16:41:12 <smcginnis> ntpttr: We usually get a google hangout going.
16:41:13 <tbarron> that's all
16:41:29 <dulek> tbarron: Oh, that's cool. I'll talk with my management.
16:41:32 <smcginnis> ntpttr: We might video stream too like we did at the summit.
16:41:41 <ntpttr> smcginnis: all right sounds good, thanks
16:41:55 <smcginnis> ntpttr: Not as good as being there, but I think it works OK.
16:41:56 <bswartz> +1 for video streaming -- google hangouts does NOT scale well
16:41:57 <ntpttr> smcginnis: yeah the youtube channel was definitely nice
16:42:08 <dulek> ntpttr: https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ
16:42:10 <kmartin> If hemnafk or I can attend, we'll bring the recording devices, etc...
16:42:26 <smcginnis> OK, good feedback. I'll see if our AV club can set something up again. (hemna) :)
16:42:39 <smcginnis> kmartin: Awesome, thank you.
16:43:03 <smcginnis> Alright, guess we're done here. Thanks everyone.
16:43:12 <geguileo> Thanks
16:43:14 <smcginnis> #endmeeting