16:00:01 <smcginnis> #startmeeting Cinder
16:00:01 <openstack> Meeting started Wed Sep  7 16:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <openstack> The meeting name has been set to 'cinder'
16:00:07 <jungleboyj> o/
16:00:09 <_alastor__> \o
16:00:11 <jgregor> Howdy
16:00:11 <smcginnis> ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylike.hu
16:00:20 <erlon> hey
16:00:20 <e0ne> hi
16:00:23 <geguileo> Hi!
16:00:26 <eharney> hi
16:00:29 <flip214> hi
16:00:33 <DuncanT> Hi
16:00:33 <bswartz> o./
16:00:38 <bswartz> .o/
16:00:49 <xyang1> hi
16:00:50 <smcginnis> https://wiki.openstack.org/wiki/CinderMeetings#Next_Cinder_Team_meeting
16:00:51 <diablo_rojo> Hello :)
16:00:55 <smcginnis> #topic Announcements
16:01:03 <Swanson> Hi
16:01:05 <scottda> hi
16:01:08 <fernnest_> hi
16:01:16 <smcginnis> #link https://releases.openstack.org/newton/schedule.html Schedule
16:01:20 <smcginnis> We're getting really close.
16:01:36 <smcginnis> As a reminder, we are past feature freeze now.
16:01:44 <smcginnis> We should only be focusing on bug fixes at this point.
16:01:57 <smcginnis> We are also past soft string freeze.
16:01:58 <tbarron> hi
16:02:21 <smcginnis> So reviewers, please watch of unnecessary external string changes and try to prevent/limit those as much as possible.
16:02:30 <Swanson> How long do we have for documentation updates?
16:02:40 <smcginnis> It seems like the translation team has been very active, but no need to create extra work for them.
16:02:45 <erlon> smcginnis: string??
16:02:47 <smcginnis> Swanson: Not really sire.
16:02:57 <smcginnis> Would have to check with the openstack-manuals team on that.
16:03:05 <smcginnis> erlon: ?
16:03:11 <Swanson> well, hop to.
16:03:24 <bswartz> erlon: soft string freeze = no changes to existing translatable strings, but new strings are permitted
16:03:25 <erlon> smcginnis: what do you mean with string changes?
16:03:35 <smcginnis> erlon: What bswartz said? :_)
16:03:49 <erlon> smcginnis: bswartz : hmmm ok thanks!! :)
16:03:51 <smcginnis> We need to limit string translation changes.
16:04:13 <smcginnis> RC1 is coming up the week of the 12th. So probably next Wednesday I will cut RC-1.
16:04:29 <smcginnis> Sooner if we are at a good point, but no sense rushing it.
16:04:39 <DuncanT> There was a patch up for cinder client adding a few dozen new strings... will go put a -2 on that for now
16:04:41 <smcginnis> Rather not have multiple RC-2, 3, etc.
16:04:59 <smcginnis> DuncanT: Not sure on client since that is already gone for Newton.
16:05:14 <DuncanT> Is there an etherpad for 'things that need to land before RC' again?
16:05:15 <smcginnis> DuncanT: Maybe OK to let that through. They probably won't look at those until O opens up.
16:05:18 <bswartz> DuncanT: new strings are less problematic than changes to strings -- the former adds more work to do, the latter throws away work already done
16:05:21 <e0ne> smcginnis: do we have buglist for RC?
16:05:47 <jungleboyj> e0ne: ++
16:05:50 <smcginnis> DuncanT, e0ne: No, but good point. We should pull that together to make sure we hit the high priority ones.
16:06:09 <smcginnis> Let
16:06:14 <smcginnis> Let's use this: https://etherpad.openstack.org/p/newton-cinder-bugtracking
16:06:32 <jgriffith> e0ne: smcginnis shouldn't we jus triage LP and mark them as RC ?
16:06:42 <e0ne> jgriffith: +1
16:06:54 <jgriffith> e0ne: smcginnis then it's easy and publicly available to just querie
16:06:55 <erlon> jgriffith: +1
16:06:56 <jungleboyj> :-)
16:07:06 <smcginnis> jgriffith: I'll do that. But might be helpful for reviewers if we have a prioritized list.
16:07:26 <e0ne> we have to set RC milestones for these bugs
16:07:33 <smcginnis> jgriffith: But if you don't think so, I'm fine scratching that off my todo list?. ;)
16:07:36 <jgriffith> smcginnis: sorry, couldn't resist another RC another chance for me to get on my soap box about this :)
16:07:45 <smcginnis> :)
16:08:15 <jgriffith> smcginnis: I've always found the *extra* lists on etherpad a bad thing.  I think we should be using the tools we have (launchpad) even if it's annoying sometimes :)
16:08:32 <erlon> smcginnis: isnt possible to prioritize in LP?
16:08:39 <smcginnis> OK, I'll try to just set targets in launchpad and try to set priorities on there.
16:08:51 <jgriffith> e0ne: no, but if things are marked as RC we should be reviewing them :)
16:08:57 <smcginnis> erlon: Yeah, I just don't like the filtering and sorting abilities of launchpad.
16:08:59 <e0ne> jgriffith: launchpad should be one source of trust, IMO
16:09:17 <jungleboyj> smcginnis: What filtering and sorting?  ;-)
16:09:27 <smcginnis> jungleboyj: Hah! Exactly.
16:09:31 <jgriffith> jungleboyj: lol
16:09:47 <bswartz> the one thing LP can't do is allow reviewers to sign up to review changes so we ensure we don't duplicate review work -- but that typically only matters for big features -- not for bugs
16:09:58 <erlon> tagging bugs to RC-x
16:10:06 <smcginnis> #action smcginnis and team to target bugs for RC and set appropriate priority for Newton tracking
16:10:17 <smcginnis> bswartz: True
16:10:42 <smcginnis> #topic What do (and don't) we want release notes for
16:10:46 <smcginnis> DuncanT: Take er away
16:10:48 <erlon> bswartz: put a tag with you name ? ^^
16:11:01 <smcginnis> erlon: There you go. ;)
16:11:11 <DuncanT> Lookin gat the agenda, we've got an answer to the question, and the request for the release note was bogus
16:11:30 <DuncanT> So, erm, reviewers, please read the (very sensible) guide before asking for release notes?
16:11:44 <smcginnis> DuncanT: OK, good. Yeah, I looked at that issue and it didn't look like it should have one.
16:12:02 <DuncanT> smcginnis: That was my starting point
16:12:04 <smcginnis> We really only need release notes for things that would be good to tell deployers and end users.
16:12:30 <smcginnis> Internal technical details would just be confusing to most of them, so they definitely should not have a RL.
16:12:35 <DuncanT> smcginnis: Ok, unless anybody wants to argue, I think that's done
16:12:49 <smcginnis> Anybody have any questions on that before we move on?
16:12:58 <jgriffith> DuncanT: did somebody invite me to argue?
16:13:01 <jgriffith> DuncanT: just kidding
16:13:03 <smcginnis> LOL
16:13:12 * smcginnis quickly types...
16:13:15 <smcginnis> #topic py35 cinder job
16:13:18 <jgriffith> haha
16:13:33 <smcginnis> dulek: Here? Or I can take it.
16:13:38 <e0ne> how much tests are failing with py35?
16:13:59 <smcginnis> I haven't looked lately but it seems like it's been pretty stable.
16:14:18 <smcginnis> Michal pointed out It's voting in Neutron, Heat, Ironic, Keystone
16:14:32 <e0ne> if all or almost all tests are passed, I'm feeling OK to add non-voting job
16:14:43 <smcginnis> Since that appears to be where we plan on going, I think we can switch it. But...
16:15:08 <e0ne> we we have any requeast or guidelines what python versions should be supported from TC?
16:15:09 <smcginnis> I'm thinking we should probably wait until RC-1 is cut, then make it voting for Ocata.
16:15:19 <smcginnis> Just so we don't cause issues for ourselves.
16:15:26 <e0ne> smcginnis: +1
16:15:26 <jungleboyj> smcginnis: +2
16:15:39 <smcginnis> e0ne: There's this: https://review.openstack.org/#/c/349069/
16:16:02 <e0ne> smcginnis: thanks!
16:16:16 <smcginnis> So unless anyone has a strong argument for why we should do it now, let's plan on switching it once Newtons out of the way.
16:16:18 <DuncanT> Yeah, bringing the job to voting before RC1 seems far more risk than reward
16:16:25 <diablo_rojo> smcginnis, +1
16:16:27 <smcginnis> DuncanT: +1
16:16:35 <diablo_rojo> DuncanT, +1
16:16:48 <smcginnis> Michal also referenced this patch: https://review.openstack.org/366739
16:16:59 <e0ne> DuncanT: +1. maybe, we should hold on it even until final release
16:17:01 <smcginnis> I left my thoughts there, but feel free to review and disagree.
16:17:03 <jungleboyj> smcginnis: +1
16:17:47 <smcginnis> #topic Proprietary libs for drivers
16:18:06 <smcginnis> I don't have a link to the current thread, but this has come up multiple times.
16:18:24 <smcginnis> We've definitely said no to wrapper drivers that just call external libs.
16:18:29 <erlon> smcginnis: do you have a list of who uses proprietary code?
16:18:43 <smcginnis> But we also have existing drivers that use at least partial proprietary libs.
16:18:44 <DuncanT> erlon: IBM is the case on the mailing list
16:18:59 <smcginnis> erlon: I don't have a list pulled together. Yet.
16:19:18 <jgriffith> fyi http://lists.openstack.org/pipermail/openstack-dev/2016-September/103030.html
16:19:19 <smcginnis> DuncanT: I was trying to avoid heartburn for jungleboyj and not mention the name. ;)
16:19:34 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/103030.html Current ML thread
16:19:36 <erlon> DuncanT: hmm, have just saw
16:19:37 <jungleboyj> smcginnis: Thank you.
16:19:40 <jgriffith> or the full thread http://lists.openstack.org/pipermail/openstack-dev/2016-September/103096.html
16:19:47 <smcginnis> So I like jgriffith's stance on there.
16:19:59 <smcginnis> I just wonder how feasible that is for all vendors.
16:20:26 <smcginnis> And where we draw the line between what is a vendor's product and what is the open source driver that works with it.
16:20:28 <jungleboyj> smcginnis: I am behind.  What is the stance?
16:20:34 <bswartz> I agree -- NetApp explored some kind of hybrid open/closed driver license combo and there was no way to make it workable
16:20:51 <smcginnis> jungleboyj: http://lists.openstack.org/pipermail/openstack-dev/2016-September/103096.html
16:20:53 <jgriffith> jungleboyj: you're either open source or you're not
16:20:56 <jgriffith> jungleboyj: period
16:21:03 <jgriffith> jungleboyj: and OpenStack is Open Source
16:21:17 <jgriffith> therefore....
16:21:18 <bswartz> the only way non-open code makes sense is if it's an external binary or service that the driver interacts with through an API or CLI -- not python code
16:21:23 <jgriffith> You can draw the conclusion
16:21:25 <erlon> jgriffith: +1
16:21:40 <smcginnis> bswartz: +1
16:21:47 <DuncanT> I'm not going to oppose jgriffith's stance after this meeting... I just don't care enough. I'll throw in a philosophical question here though: If the backend was all software (like ceph) and closed source, where do you draw the line between driver and product?
16:22:06 <DuncanT> An API or CLI sounds like a good answer to me
16:22:07 <jgriffith> DuncanT: I think you're missing the point I was making
16:22:09 <smcginnis> DuncanT: That's my dilemma.
16:22:13 <jungleboyj> DuncanT: Thank you.  That was what I was going to ask.
16:22:17 <jgriffith> DuncanT: I don't care if you're "device" is proprietary
16:22:31 <hemna> fwiw there are some drivers that use external proprietary apps to do work as well
16:22:47 <jgriffith> DuncanT: I *do* care that you dump *partial* code or driver in Cinder and then say "download my private lib to make it work and install it on your cinder nodes"
16:22:47 <jungleboyj> jgriffith: Ok, then why do you care if I have a library that is utilized to talk to the backend?
16:22:49 <jgriffith> F'that
16:22:54 <smcginnis> So a lib interacting with a device is not the device. So the device can be closed but the lib cannot. I think that's what we're saying.
16:22:55 <bswartz> DuncanT: I think you could draw the line at the process boundary of the c-vol process
16:22:58 <hemna> jungleboyj, +1
16:23:04 <jgriffith> jungleboyj: I think I've been very clear on why I care
16:23:20 <jgriffith> jungleboyj: but I'll say it again and please reference my response on the ML
16:23:31 <jgriffith> jungleboyj: hemna OpenStack is an Open Source project!
16:23:33 <DuncanT> jgriffith: Ok, thanks for clarifying
16:23:37 <jgriffith> It's NOT a hybrid
16:23:48 <jgriffith> It's NOT a place for Vendors to game the system
16:23:57 <e0ne> jgriffith: +1, it's a very good point
16:23:59 <hemna> yes of course it is
16:24:01 <jgriffith> It's NOT a marketing platform for vendors that don't give something back
16:24:06 <hemna> and the code checked into cinder is opensource
16:24:20 <jgriffith> and if you haven't read it, you should read the "4 opens" of OpenStack
16:24:25 <jungleboyj> jgriffith: I want to make sure we are not arguing two different things here.
16:24:37 <jgriffith> jungleboyj: we could be :)
16:24:46 <jungleboyj> So, I totally agree that what XIV currently has is not right and I am doing what I can to fix that.
16:25:02 <hemna> and the vendor in this case is IBM which has "given something back"  in this case.
16:25:27 <jungleboyj> What has been proposed is open sourcing of all the Cinder Python code that currently makes XIV work.
16:25:58 <jgriffith> "while keeping the connectivity to the storage as closed source"
16:26:19 <jgriffith> jungleboyj: So what I understand about how that works is thus...
16:26:25 <jungleboyj> Correct.  Because the library used is 300k plus lines of code that is used for many other things.
16:26:27 <jgriffith> jungleboyj: Hey.. install and setup OpenStack
16:26:44 <jgriffith> NOW if you want to enable xiv then you have to install this special proprietary closed source lib to make it work
16:26:57 <DuncanT> jungleboyj: Will this library be on PIP?
16:27:07 <jgriffith> That's EXACTLY the thing that DuncanT and Redhat had issues with Netapp over back around Tokyo timefram
16:27:10 <jgriffith> timeframe
16:27:16 <jungleboyj> DuncanT: I am not sure about that.
16:27:20 <jgriffith> it creates licensing issues for those distros too
16:27:33 <bswartz> jgriffith: +1
16:27:53 <hemna> why do the distros even care.  just don't ship that library.
16:27:56 <smcginnis> eharney: Any thoughts on this from a distro perspective?
16:27:59 <DuncanT> jgriffith: If the the 'closed source' license is anything other than 'distro can copy this, package this, etc etc' then I'm 110% against it, for sure
16:28:00 <jgriffith> I'm cofused because when Netapp proposed a proprietary licenesed lib (albeit open source) the distros flipped
16:28:00 <jungleboyj> hemna: ++
16:28:10 <jgriffith> hemna: jungleboyj alright... I give up
16:28:15 <jungleboyj> jgriffith: We don't require that the backends opensource their code.
16:28:16 <jgriffith> you were both in the room
16:28:32 <hemna> jgriffith, I'm honestly curious why the distros care about it though
16:28:35 <jungleboyj> jgriffith: Yes we were and we never agreed on this point.
16:28:37 <hemna> I'm not trying to be difficult
16:28:38 <smcginnis> jgriffith: I think the NetApp issue was they took the open code and tried to relicense it, TBF.
16:28:39 <jgriffith> hemna: licensing
16:28:46 <jungleboyj> smcginnis: ++
16:28:46 <hemna> but they don't have to ship the library
16:28:48 <jgriffith> smcginnis: yes, that was an issue as well
16:28:58 <DuncanT> jgriffith: You're right that it absolutely, 100% needs a freely redistributable library
16:28:58 <bswartz> smcginnis: that was a small part of the issue, but not the main sticking point
16:29:04 <jungleboyj> Copying the code into a closed library is not ok.
16:29:06 <jgriffith> hemna: jungleboyj ok, IBM and HP do whatever ya like.  You're both core
16:29:11 <jgriffith> I won't stand in your way
16:29:17 <hemna> I'm just asking questions
16:29:18 <jungleboyj> jgriffith: It isn't just us.
16:29:19 <eharney> smcginnis: open source is good, closed libs are problematic
16:29:22 <hemna> because I'm curious
16:29:25 <DuncanT> hemna: Helion etc need to be able to ship the library.... I'm a hard -2 if we can't
16:29:45 <scottda> It does make it hard for a distro to say "any driver in tree will work with our distro, except for x, y, and z, which need further code installed.
16:29:48 <jungleboyj> DuncanT: What do you mean ship the library?
16:29:48 <jgriffith> DuncanT: and yes, you were one of the biggest opponents to the proprietary license risk IIRC
16:29:52 <smcginnis> DuncanT: how does helion handle this now?
16:30:00 <hemna> scottda, so it's for convenience
16:30:00 <scottda> jungleboyj: Package and ship the library
16:30:18 <scottda> hemna: It's for support as well
16:30:20 <DuncanT> jungleboyj: We need to be able to package the library as part of helion, and copy it to any nodes we want, etc
16:30:34 <jgriffith> jungleboyj: hemna how does a distro put together an Open Source project like OpenStack if there are required libs that have proprietary licenses in them?
16:30:53 <hemna> well, they don't have to support those drivers though either
16:31:07 <jungleboyj> DuncanT: Ok, I am not sure where we stand on that, I need to get more info on my end.
16:31:09 * flip214 is reminded of the flash-downloader-scripts that are being packaged...
16:31:15 <hemna> heh
16:31:21 <DuncanT> jungleboyj: jgriffith: Licenses that didn't make the library freely redistributable are definitely a problem
16:31:23 <jungleboyj> hemna: True.
16:31:26 <eharney> flip214: not in RHEL
16:31:30 <e0ne> but they can't drop cinder drivers. they will just ship non-working driver is such case
16:31:38 <jgriffith> eharney: +1 :)
16:31:47 <e0ne> DuncanT: +1
16:32:05 <DuncanT> e0ne: Who can't drop drivers?
16:32:11 <eharney> of course they can drop drivers
16:32:25 <jungleboyj> Alon isn't online right now so I can't follow up immediately on the distributable nature.
16:32:25 <hemna> on the flip side, there is nothing preventing a vendor from releasing a cinder driver to github that includes a readme to install the proprietary library.  it just doesn't go with cinder and distros.
16:32:45 <jungleboyj> hemna: Others have done that and I think it is worse.
16:32:47 <e0ne> DuncanT: distros. if some driver requires proprietary lib, distos won't ship lib and won't cut such drivers
16:32:55 <jgriffith> let me ask a simple question... is this in the best interest of OpenStack and the Cinder?
16:32:57 <erlon> hemna: Hitachi does that
16:33:03 <e0ne> hemna: +1
16:33:05 <jgriffith> or is it only in the interest of the Vendors involved?
16:33:20 <jgriffith> s/and the/and then/
16:33:26 * jungleboyj will abstain from voting
16:33:28 <erlon> hemna: so we can always push changes if needed, directly to the client
16:33:29 <hemna> I'd much rather have completely opensource for sure.  I'm simply asking questions to find out what the real issue is.
16:33:48 <jgriffith> hemna: OpenStack is an Open Source project no?
16:33:48 <jungleboyj> hemna: I agree.
16:34:04 <hemna> jgriffith, of course.  I think you are misunderstanding my questions.
16:34:12 <hemna> I'm not advocating closed source
16:34:24 <jgriffith> sorry... I should've just kept my mouth shut and let everybody move along.  I seem to be the only one that really cares about this
16:34:25 <hemna> I freely admit I'm not a licensing lawyer.
16:34:26 <e0ne> as a vendor, I would like to ship only drivers which can work out-of-the-box
16:35:00 <scottda> e0ne: I agree
16:35:05 <hemna> as someone that has released required libraries for my drivers.....using the same license as openstack.
16:35:07 <jgriffith> e0ne: and that's typically the feedback I receive from customers as well
16:35:15 <DuncanT> jgriffith: No, you shouldn't. And you don't seem to be the only one who cares...
16:35:17 <jgriffith> hemna: and that's different
16:35:46 <scottda> Helion customers don't want to be locked in to any storage, especially HPE storage. They want OpenStack to be open source and work out-of the box with any driver in -tree
16:35:47 <jgriffith> hemna: you're still making them open and you're using a compatable license... so even if I find it annoying there's nothing wrong with it
16:36:21 <DuncanT> jgriffith: If the license is "you can copy, redistribute and repackage this as required" are you still firmly against it? That covers the 'working out of the box' think.... you can even put it up on pip then
16:36:32 <hemna> It would be great if everyone did that.....use the same license.
16:36:33 <jgriffith> AFAIC folks that want this type of model should just do it all in closed/proprietary and move along
16:36:36 <hemna> and opensource it.
16:36:59 <jungleboyj> jgriffith: That is going totally the opposite direction?
16:37:11 <jungleboyj> We are trying to get things as open as possible.
16:37:24 <e0ne> jgriffith: +1. vendors should care about licensing, instead of us
16:37:31 <jgriffith> jungleboyj: You're only trying to serve your best interests and have your cake and eat it too
16:38:00 <jungleboyj> I am frustrated by the fact that if I asked you to release the code that runs on your backend you would probably incredulous.  Unfortunately we have a library instead that is loaded.
16:38:15 <scottda> Vendors do care about liscensing. And we indemnify our customers against liscensing issues, so we have to be very careful about what we ship.
16:38:17 <jgriffith> jungleboyj: that's completely different
16:38:28 <hemna> jungleboyj, didn't you say you are working on fixing that and going to release an opensouce lib for the offending driver?
16:38:28 <jungleboyj> jgriffith: That is not fair of you to say.
16:38:29 <jgriffith> jungleboyj: You really don't see the difference here?
16:38:57 <jgriffith> jungleboyj: you don't see the difference in "here's everything you need to run in cinder" with the exception of the backend itself?
16:39:05 <jungleboyj> jgriffith: The difference is with licensing for the packagers.
16:39:24 <jungleboyj> jgriffith: That is true for most vendor backends.
16:39:34 <smcginnis> scottda, DuncanT: Are there a list of drivers that are not supported out of the box with Helion right now?
16:39:35 <jungleboyj> We don't sell Cinder with the backends included.
16:39:36 <jgriffith> jungleboyj: and saying "here's the cinder code, but it's actually incomplete and useless until you add this connector/lib shim that runs on openstack nodes?
16:39:44 <e0ne> jungleboyj: ceph is not a best example in this case, but I like it's model: I consume ceph binaries only (like a vendor's hardware in other case) and use opened client for it
16:39:55 <jgriffith> e0ne: +1
16:40:09 <jgriffith> and that's how *most* drivers in Cinder work.
16:40:27 <jungleboyj> jgriffith: And you comment about only caring about my best interests is totally unfair.  Now others are going to get scrutiny because of this and I fell bad for that.
16:40:40 <DuncanT> smcginnis: Not yet, it's all a bit up in the air, and there are lots of definitions of 'supported'. We haven't yet removed any drivers from the code, since licensing issues have thus far been solved int he right place (here)
16:41:07 <smcginnis> DuncanT: But there are some that require a closed library right now. Those just don't work out of the box?
16:41:18 <jungleboyj> So rather than throwing stones at eachother lets talk out some possible options/compromises.
16:41:31 <hemna> so to play devil's advocate, there are several os-brick connectors that require installs of tools as well
16:41:39 <jungleboyj> smcginnis: Is there anyone else that is going to be hit by this requirement that there be now closed source library?
16:41:40 <jgriffith> jungleboyj: I"m not throwing stones at anybody... I'm just trying to make a point
16:41:41 <hemna> so they don't work out of the box unless something is installed as well.
16:41:54 <smcginnis> jungleboyj: That's what I'm trying to figure out.
16:41:56 <jungleboyj> jgriffith: Point made.  Moving on.
16:42:06 <jungleboyj> hemna: Good point.
16:42:06 <DuncanT> smcginnis: And if we can't ship the libraries, when we list supported drivers, those won't be on it (and efforts to fix that, namely me being here complaining, plus a formal approach to the tC if needed) will be made
16:42:09 <bswartz> jungleboyj: one of the EMC drivers uses a proprietary binary on the cinder host to communicate with their backend -- that seems like a workable model
16:42:13 <DuncanT> smcginnis: We're just behind the curve
16:42:16 <hemna> emc, hgst, etc
16:42:22 <DuncanT> smcginnis: Do you know which drivers are a problem?
16:42:37 <smcginnis> DuncanT: XIV for one, but I know there are others.
16:42:39 <jungleboyj> bswartz: Is it with a compatible license?
16:42:39 <hemna> bswartz, but it's the same arugment, you must install something for the driver to work.
16:42:42 <hemna> it's not out of the box.
16:42:51 <DuncanT> smcginnis: I'll take a look, thanks
16:42:56 <smcginnis> SO I don't think Helion actually can support all drivers out of the box today.
16:43:01 <bswartz> jungleboyj: the binary is closed/proprietary -- but it's not a python lib it's a separate program
16:43:21 <tbarron> there may be implications here I think for security vulnerabiility managed label from openstack
16:43:27 <jungleboyj> bswartz: Ok, so in jgriffith argument I don't think that would be acceptable either.
16:43:28 <smcginnis> tbarron: Good point.
16:43:30 <DuncanT> Is it worth agreeing to come back to this when people have had chance to do their research?
16:43:35 <xyang2> bswartz: I need to double check on that.  VNX did have a CLI that is exe that is C code, not python.  they moved stuff to pypi lately, not sure if that is still required
16:43:39 <smcginnis> DuncanT: +1
16:43:50 <jungleboyj> DuncanT: +1
16:43:54 <jgriffith> jungleboyj: how about you outline exactly what it is that you guys want to do here?
16:43:56 <tbarron> cinder has that label grandfathered today but  POR is that to keep it work will have to be done
16:44:03 <hemna> so I see 2 problems here really:  1) the license of the code included in Cinder and 2) what's required to make the driver work.
16:44:04 <xyang2> hemna: in ScaleIO case, the storage device is software based
16:44:04 <jgriffith> jungleboyj: maybe it doesn't matter
16:44:05 <bswartz> in fact NetApp has a driver which relies on an external proxy (closed source, Java code) with a REST API to communicate with one of our controllers
16:44:06 <jungleboyj> I need to get this info back to the team here.
16:44:12 <DuncanT> I'd be against any driver where a distro can't ship everything, out of the box, to work
16:44:21 <tbarron> work that involves being able to get under the hood and inspect the engine
16:44:49 <e0ne> DuncanT: I'm agree with you
16:44:50 <hemna> xyang2, I don't see that as a relavant point here.
16:44:55 <smcginnis> Let's do a little homework so we have some actual data behind some of this, then come back to it.
16:44:56 <DuncanT> tbarron: But we don't have the source for backends, and they tend to be full of security issues
16:45:00 <scottda> Can we set the goal of coming to a decision in Barcelona? We keep coming back to this issue.
16:45:06 <smcginnis> scottda: +1
16:45:09 <jungleboyj> scottda: +1
16:45:19 <hemna> DuncanT, then we need to remove some EMC drivers, HGST and a few others from cinder and os-brick.
16:45:24 <hemna> because that's how they are today.
16:45:26 <xyang2> hemna: I'm saying just like hardware based device has everything on hardware you need to buy hardware to run it
16:45:27 <tbarron> DuncanT: yeah, so the backend isn't managed for vulnerabilities, but the driver is
16:45:29 <smcginnis> We have an option for an extra fishbowl. This sounds like it might be a good one for that.
16:45:33 <jgriffith> scottda: we already have at a higher level:  https://governance.openstack.org/reference/opens.html
16:45:35 <jungleboyj> Can I request, in the case that we are going to change our stance on external libraries that we have a deprecation period of some sort.
16:45:39 <xyang2> hemna: in this case, everything is software for ScaleIO
16:45:45 <smcginnis> Try to get some vendors and deployers in the room to discuss it.
16:45:54 <jungleboyj> smcginnis: ++
16:45:57 <hemna> xyang2, but the backend is separate from the tools/apps/libs required to talk to it.
16:45:59 <scottda> jgriffith: I'm not disagreeing with you
16:46:00 <erlon> smcginnis: +1
16:46:01 <DuncanT> hemna: in which case, we should get an agreed stance and start looking at removing them in 'O' as far as I'm concerned.
16:46:14 <xyang2> hemna: but if this becomes a requirement that every lib has to be open source, we could look at how to resolve it
16:46:26 <jgriffith> scottda: I wasn't saying you were... You asked if we could settle this, I'm saying I think it's already settled via governance
16:46:30 <hemna> xyang2, sure, I'm all for that.
16:46:42 <DuncanT> hemna: I'd need to read the licenses to be sure. Documenting what drivers/backends require what extra parts is a first step
16:46:56 <hemna> DuncanT, ok, I can do that for os-brick at least.
16:47:01 <xyang2> hemna: problem is how to make sure every single driver gets the same attention:)
16:47:02 <DuncanT> hemna: Awesome
16:47:02 <hemna> there are a few
16:47:03 <smcginnis> hemna: That would be great.
16:47:19 <hemna> I'd like to resolve this and get everyone happy and included in tree.
16:47:25 <jgriffith> one last comment... because It's the perfect opportunity "out of tree drivers"  :)
16:47:28 <jgriffith> problem solved
16:47:37 <hemna> if that requires working towards open sourcing apps/libs, then so be it.
16:47:39 <e0ne> jgriffith: :)
16:47:44 <hemna> jgriffith, :)
16:47:47 <smcginnis> jgriffith: I was waiting for that. :)
16:48:03 <jgriffith> I resisted as long as I could... really I did :)
16:48:14 <hemna> jgriffith, so, why can't we create a sideload mechanism for that today?
16:48:21 <DuncanT> jgriffith: All drivers going out of tree gives up the in-tree advantages for vendors who play fair though
16:48:25 <jgriffith> hemna: we already have one :)
16:48:27 <smcginnis> hemna: 2nd class drivers? :)
16:48:34 <jgriffith> hemna: there are people already doing that today
16:48:40 <jgriffith> smcginnis: +1
16:48:43 <hemna> jgriffith, I mean with a way to register those from pip
16:48:44 <DuncanT> hemna: It's already there. It just works. HP public cloud did it just fine.
16:49:06 <DuncanT> hemna: Why? You just put the full class in the config file. Why mess with pip voodoo?
16:49:09 <hemna> anyway, we can talk about it offline
16:49:10 <jgriffith> hemna: vendors can do it however they want, that's the beauty
16:49:16 <hemna> yah I know
16:49:27 <hemna> I'm thinking something else
16:49:30 <jungleboyj> Round and round we go.
16:49:31 <jgriffith> and it's strictly *their* problem
16:49:37 <smcginnis> Really, it is easy enough to install a separate package to add a driver and just configure the cinder.conf settings. I just don't want to lose the reviews and quality assurances of having most be in tree.
16:49:38 <jgriffith> jungleboyj: actually we're not
16:49:41 <hemna> we can take it offline
16:49:49 <jgriffith> jungleboyj: they're very different problems and statements
16:50:15 <jgriffith> It's the "I want it both ways, that is the problem"
16:50:19 <jungleboyj> smcginnis: I agree, but that doesn't seem to be the consensus here.
16:50:23 <jgriffith> I want it in tree except the parts that aren't
16:50:30 <jgriffith> I want it open source, except the parts that aren't
16:50:58 <jgriffith> in other words, I just want to do the thing that suite me
16:51:05 <DuncanT> jgriffith: I want vendors to be able to have everything work out of the box
16:51:10 <smcginnis> And here I thought we might end early today...
16:51:11 <jungleboyj> I will go do my homework and see what I can figure out.
16:51:12 <jgriffith> DuncanT: agreed
16:51:18 <bswartz> let's all post to the ML thread and try to make progress on this topic there
16:51:21 <jgriffith> smcginnis: sorry... I'll stop now I promise
16:51:25 <smcginnis> :)
16:51:25 * jgriffith goes silent
16:51:44 <flip214> perhaps an etherpad would be better for such brainstorming
16:51:44 <smcginnis> bswartz: Yes, if you have a strong opinion, please respond to the thread
16:51:54 <flip214> the individual thoughts could be accumulated better
16:51:58 <DuncanT> bswartz: Posting to the mailing list never makes progress on anything, and a whole bunch of non-cinder folks with zero background will chime in at random
16:52:03 <smcginnis> In the meantime I'll try to do a little homework and figure out the real state of our current drivers.
16:52:03 <hemna> flip214, I might create one just to dump my idea on the out of tree drivers idea
16:52:14 <jungleboyj> smcginnis: Thank you.
16:52:16 <flip214> hemna: please share the link in the ML thread
16:52:31 <jungleboyj> I need to get Alon pulled in more as he is the one with the real skin in the game here.
16:52:31 <flip214> perhaps I've got one or two thoughts worth sharing
16:52:33 <smcginnis> And we can plan a session at Barcelona to discuss a final, and clear, statement for what's allowed and what's not so we don't have to do this again.
16:52:45 <scottda> smcginnis: +10000
16:52:45 <jungleboyj> smcginnis: ++
16:53:08 <xyang2> smcginnis: I wonder how you can tell if driver doesn't document it needs it?
16:53:09 <Swanson> smcginnis, "final, and clear" heeheehe
16:53:11 <flip214> please make it .5 hours, but plan for 4
16:53:33 <flip214> don't think it'll be any faster than this discussion here
16:53:35 <hemna> smcginnis, https://etherpad.openstack.org/p/cinder-brick-driver-externals
16:53:49 <DuncanT> xyang2: If a vendor pulls that, you remove the driver, perminently, and publicly shame them
16:53:53 <flip214> well, perhaps it is, in case the basic thoughts are already summarized ^^ hemna
16:53:54 <hemna> smcginnis, I'm adding notes to there for os-brick connectors
16:54:18 <smcginnis> hemna: Thanks!
16:54:21 <DuncanT> hemna: I'll add license details I can find for each one
16:54:30 <DuncanT> hemna: If you don't
16:54:48 <smcginnis> At least it's easy to get a list of all our drivers now. Should be able to brute force it and go one by one through the list and look at what they're doing.
16:54:49 <xyang2> DuncanT: I'm not sure how it can be thorough, but I hope it can
16:55:14 <DuncanT> xyang2: You can read the code and get a good idea
16:55:24 <DuncanT> xyang2: That's entirely doable if needed
16:55:39 <smcginnis> Anything else in the last few minutes?
16:55:55 * jungleboyj curls up in a ball in the corner.  ;-)
16:55:56 <erlon> smcginnis: the last topic?
16:55:59 <xyang2> smcginnis: what is the timeline?
16:56:07 <erlon> smcginnis: that a quick one
16:56:09 <smcginnis> erlon: Oh, was one added?
16:56:20 <smcginnis> xyang2: ASAP. :)
16:56:23 <smcginnis> #topic Volume extend errors and scheduler decisions
16:56:24 <erlon> smcginnis: just want to bring some focus in this patch: https://review.openstack.org/#/c/341136/
16:56:27 <smcginnis> erlon: Go for it.
16:56:39 <erlon> It fixes an bug in the extend volume, but it adds a lot of code that is similar to what scheduler do/should do. So, it bright some questioning about wether we should fix this in manager or move those kind of decisions to the scheduler.
16:56:49 <xyang2> smcginnis: please specify a deadline, this can't be done in a day though
16:57:03 <erlon> brings
16:57:04 <smcginnis> xyang2: How about next week's meeting.
16:57:19 <erlon> Are you folks ok if we merge this using this approach and pick this in O with more discussion/spec etc?
16:57:21 <xyang2> smcginnis: to get everything converted?  not possible
16:57:39 <smcginnis> xyang2: To get info about the drivers.
16:57:52 <xyang2> smcginnis: ok
16:57:55 <smcginnis> erlon: So I think it probably makes sense to fix for now, and get it right next release.
16:58:05 <smcginnis> erlon: Is there a bug open to track that?
16:58:26 <erlon> smcginnis: ok, only this extend, the broather change still needs an spec
16:58:47 <erlon> smcginnis: ok, if you can give a look please
16:58:50 <smcginnis> erlon: Please ping me when that's available.
16:58:54 <xyang2> erlon: it's a lot of duplicate code to add to manager.
16:59:02 <smcginnis> erlon: I'll take a look at the current patch hopefully today.
16:59:32 <smcginnis> OK, thanks everyone.
16:59:37 <erlon> xyang2: agreed, but its jsut a questions of leaving the bug open or not
16:59:38 <xyang2> erlon: I don't know what is the best way to get it fixed in a short time.  refactor involves changes to scheduler and it is risky too
17:00:00 <tbarron> thanks
17:00:03 <smcginnis> #endmeeting