15:00:21 <bswartz> #startmeeting manila
15:00:23 <openstack> Meeting started Thu Mar 23 15:00:21 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:26 <openstack> The meeting name has been set to 'manila'
15:00:27 <jungleboyj> o/
15:00:30 <cknight> Hi
15:00:34 <xyang2> hi
15:00:35 <bswartz> hello all
15:00:36 <vponomaryov> hello
15:00:40 <ganso> hello
15:00:48 <tommylikehu_> ganso: hello
15:01:03 <vkmc> hi hi o/
15:01:05 <jprovazn> hi
15:01:09 <tbarron> hi
15:01:10 <vponomaryov> ganso: tommy respects only you ))
15:01:15 <arnewiebalck> hi
15:01:19 <bswartz> no announcements today
15:01:21 <tommylikehu_> vponomaryov: ...
15:01:23 <ganso> vponomaryov: lol
15:01:33 <tbarron> ganso: hi
15:01:36 <zhongjun_> hi
15:01:36 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:42 <vponomaryov> ganso: hi
15:02:12 <ganso> vponomaryov, tbarron, tommylikehu_ : hello :)
15:02:21 <bswartz> #topic SSL certificate verification
15:02:49 <bswartz> this issue popped up late last week and I thought it would be good to bring it up here
15:02:55 <vponomaryov> for API? drivers?
15:03:12 <bswartz> this is a py27 change
15:03:59 <dustins> hey all!
15:04:00 <bswartz> between py 2.7.8 and 2.7.9, the SSL library switched from not verifying SSL certs by default to verifying by default
15:04:20 <bswartz> in either case the behavior is configurable but the default changed and most people use the default
15:04:47 <markstur> hi
15:04:58 <bswartz> Apparently it's relatively common for people to actually use HTTPS an not verify certificates, even though it's bad security practice
15:05:33 <clarkb> my understanding was older python couldnt be made to do it instead you had to install extra libs (hence the urllib3 insecure platform warning)
15:05:46 <bswartz> NetApp first noticed this issue back during ocata when our driver started having issues communicating with some backends using HTTPS
15:06:05 <bswartz> clarkb: I wasn't aware of that -- that explains some things
15:06:48 <bswartz> in any case the initial response was to turn create an option to turn off SSL cert verification in our driver, but I pushed back against that solution
15:06:56 <clarkb> I should clarify older python stdlib couldnt do it
15:07:37 <bswartz> My stance is that SSL certification verification is there for a reason, and it's better to show users how to use it correctly than to give them a switch to turn it off
15:08:24 <bswartz> users who _really_ don't want to do the work of setting up SSL right still have the option to use HTTP or downgrade to python 2.7.8
15:09:26 <jungleboyj> Seems reasonable.
15:09:35 <bswartz> anyways the issue popped up again because EMC encountered the same issue and pushed a bugfix to disable SSL cert verification in their driver, but did it using a global driver option
15:09:54 <bswartz> I have reverted that bugfix https://review.openstack.org/#/c/447065/
15:10:11 <bswartz> and the remaining issue is how to solve EMC's problem
15:10:16 <markstur> it is good to be able to turn it off in test labs
15:10:27 <bswartz> markstur: I disagree
15:10:42 <bswartz> it's good to setup SSL properly in your test labs
15:11:04 <bswartz> or test with HTTP
15:11:12 <xyang2> bswartz: I thought you are okay for a driver only fix?
15:11:38 <bswartz> anyways the current proposal is to introduce an EMC-only driver option to disable SSL cert verification, and I'm okay with that
15:11:39 <clarkb> its trivial to properly trust a self signed cert fwiw
15:11:58 <markstur> s/it is good/it is sometimes necessary (and evil...)/
15:12:06 <bswartz> but I don't want anyone getting the idea that's is a recommended practice
15:12:37 <tbarron> xyang2: I have some concern with driver only fix unless the option is marked 'testing...' or whatever
15:12:47 <tbarron> xyang2: from a distro and support POV, #1
15:13:12 <tbarron> xyang2: and #2, from manila seeking managed-vulnerability-status from OpenStack security
15:13:14 <ganso> tbarron: from my understanding, that was targetting production clouds
15:13:42 <tbarron> ganso: ?  so why would a production cloud want to run w/o cert for https?
15:13:56 <bswartz> xyang2: I would hope that the EMC driver option default to true (verify certificates unless the admin specifically disables it)
15:14:04 <xyang2> tbarron: default to true, is ok?
15:14:15 <ganso> tbarron: I don't know, EMC should have the answer to that
15:14:29 <bswartz> xyang2: maybe log a warning when it's turned off, explaining the risks
15:14:40 <xyang2> bswartz: ok
15:14:58 <tbarron> xyang2: yeah, something loud that support people will see
15:15:15 <bswartz> the truth is that most admins are dumb and will take the path of least resistance to make things work
15:15:39 <bswartz> which is why I applaud the python community for making it harder to use SSL without certificate validation
15:16:39 <bswartz> as developers we have responsibility to make things secure by default and make it clear when options are changed to compromise security
15:16:58 <vkmc> bswartz++
15:17:04 <zhongjun_> lol
15:17:21 <jungleboyj> Truth.
15:17:29 * bswartz gets off his soap box
15:17:53 <bswartz> #topic Specs
15:18:04 <bswartz> #link https://review.openstack.org/#/q/status:open+project:openstack/manila-specs
15:18:54 <bswartz> specs deadline is in 3 weeks
15:19:11 <bswartz> please be reviewing specs
15:19:25 <bswartz> are there any spec-review-related issues we should discuss here today?
15:20:32 <bswartz> zhongjun_: you have the most open specs for pike
15:20:35 <tbarron> https://review.openstack.org/#/c/447021/ is a good spec but needs an implementor
15:20:51 <tbarron> ^^ if anyone is interested
15:20:58 <zhongjun_> bswartz: yes, please review my specs
15:22:03 <tbarron> ^^ should largely be a port from cinder
15:22:07 <bswartz> also I should point out that while pike is a longer release, we have fewer people actively working on the team now :-( so we need to be mindful of core reviewer bandwidth
15:22:43 <bswartz> we will most likely need to make some priority calls about what we focus on in Pike
15:23:11 <bswartz> and some perfectly good specs and/or ideas might not get approved just so we can focus on the high priority stuff
15:23:48 <vkmc> more eyes on this would be appreciated https://review.openstack.org/#/c/445441/
15:24:09 <bswartz> tbarron: why would Arne Wiebalck propose a spec he doesn't plan to work on?
15:24:22 <vkmc> with a high interest with regards to the perf section
15:25:01 <zhongjun_> How to define which spec is perfectly good specs? :D
15:25:02 <tbarron> bswartz: arnewiebalck is running a very big cloud full time, I think it's great to have operators proposing work for us
15:25:07 <arnewiebalck> bswartz: b/c I’d like that feature to operate Manila in our cloud
15:25:19 <tbarron> instead of us just coming up a priori with ideas of what operators need
15:25:34 <bswartz> arnewiebalck: hi!
15:25:47 <arnewiebalck> bswartz: o/
15:26:09 <arnewiebalck> bswartz: besides, I wouldn’t call myself a developer :)
15:26:19 <bswartz> okay I would just assume that operators would work with a developer to produce a spec that the developer would go on to implement
15:26:39 <bswartz> it's great to get input from operators
15:27:05 <bswartz> but a spec with no implementor does create problems for us
15:27:06 <arnewiebalck> bswartz: I thought defining more precisely what I’d need would helkp finding a dev
15:27:19 <bswartz> I guess it's good to raise awareness that we need a volunteer here
15:27:57 <bswartz> and hopefully it's obvious to everyone that working on something that a deployer asks for is way more likely to be useful that working on stuff we dream up ourselves
15:28:00 <bswartz> :-)
15:28:32 <vponomaryov> actually, I can take it
15:28:39 <vkmc> if the implementation is not very complex (I need to read the spec), we may be able to get an intern from Outreachy to work on that
15:28:51 <vkmc> or Valeriy :)
15:28:51 <bswartz> Outreachy?
15:29:01 <vkmc> yeah it's an internship project we have in OpenStack
15:29:04 <bswartz> ah
15:29:06 <vkmc> s/project/program/g
15:29:34 <tbarron> and btw vkmc's spec https://review.openstack.org/#/c/445441/ for telemetry is actual operator/customer demanded also
15:29:45 <bswartz> we have a bunch of shovel-ready work for interns who want to contribute
15:29:56 <jungleboyj> If it is just a port from Cinder it shouldn't be that bad.
15:30:10 <tbarron> jungleboyj: +1
15:30:32 <arnewiebalck> i referenced the Cinder commit in the spec
15:30:37 <bswartz> vponomaryov: if you're interested please take a look
15:30:47 <bswartz> I'm curious to know how much work this is
15:30:48 <vponomaryov> bswartz: ok
15:30:48 <vkmc> oh nice... yeah, in that case it could be ok
15:31:30 <jungleboyj> vkmc:  If you have someone Outreachy for it I can be available to help understand the Cinder side as they bring it over.
15:31:51 <tbarron> well vponomaryov will probably have it done tomorrow :)
15:31:51 <vkmc> jungleboyj, that would be awesome!
15:31:58 <vkmc> yeah :)
15:32:03 <vkmc> tbarron, ^
15:32:29 <tbarron> but jungleboyj there's more gold where that came from
15:32:38 <jungleboyj> :-)  Is he the Gorka of Manila tbarron  ?
15:33:37 <bswartz> okay I think that covers specs
15:34:04 <bswartz> please review them, please don't feel bad about pushing for reviews if you're an author
15:34:08 <bswartz> #topic open discussion
15:34:13 <bswartz> any other things for today?
15:34:39 <tommylikehu_> wait
15:35:07 <tommylikehu_> hope someone would like to take a look
15:35:08 <tommylikehu_> https://review.openstack.org/#/c/448384/
15:35:22 <tommylikehu_> I am proposing this in cinder, but we also have this in manila
15:36:45 <bswartz> tommylikehu_:  is there a spec for that, or just the change?
15:37:03 <tommylikehu_> it's a idea
15:37:22 <jungleboyj> tommylikehu_:  Is this THE change?
15:37:32 <tommylikehu_> jungleboyj: yes
15:37:41 <jungleboyj> Ah, yes it is.  :-)
15:37:57 <tommylikehu_> I hope I can get more response
15:37:59 <tommylikehu_> just that.
15:38:14 <jungleboyj> So, I looked at that more this morning and my confusion was I didn't even know that change had gone in place.
15:38:18 <bswartz> okay and I see that jprovazn already saw it so hopefully the idea can be integrated into the manila user messages work if it makes sense
15:38:24 <tbarron> tommylikehu_: thank you for working for consistency across the two projects where it matters, despite jgriffith saying he doesn't give a @#$#@ about what manila does :)
15:38:38 <jungleboyj> tbarron: ++
15:38:40 <tommylikehu_> tbarron: lol
15:38:49 <tommylikehu_> tbarron: you checked the history
15:39:14 <jungleboyj> tommylikehu_:  I will go comment in the review.  See what others think.  Thank you for the updates and bearing with me on that.
15:39:14 <jprovazn> tommylikehu_, bswartz: yes, I like the idea in the patch and if manila user messages spec will be accepted I hope we can use the same too
15:39:25 <bswartz> k
15:39:39 <tommylikehu_> thanks. jprovazn, jungleboyj, tbarron:)
15:40:04 <tommylikehu_> We can do this after meeting
15:40:15 <bswartz> alright if there's nothing else we're done
15:40:21 <bswartz> thanks everyone
15:40:32 <bswartz> #endmeeting