Open Stack

On 09/08/2016 04:41 PM, Duncan Thomas wrote:
> On 8 September 2016 at 20:17, John Griffith <john.griffith8 at gmail.com
> <mailto:john.griffith8 at gmail.com>> wrote:
>
>     On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <fungi at yuggoth.org
>     <mailto:fungi at yuggoth.org>> wrote:
>
>
>
>
>         <snip>
>
>         they should be able to simply install it and its free dependencies
>         and get a working system that can communicate with "supported"
>         hardware without needing to also download and install separate
>         proprietary tools from the hardware vendor. It's not what we say
>         today, but it's what I personally feel like we *should* be saying.
>
>
>     Your view on what you feel we *should* say, is exactly how I've
>     interpreted our position in previous discussions within the Cinder
>     project.  Perhaps I'm over reaching in my interpretation and that's
>     why this is so hotly debated when I do see it or voice my concerns
>     about it.
>
>
> Despite the fact I've appeared to be slightly disagreeing with John in
> the IRC discussion on this subject, you've summarised my concern very
> well. I'm not convinced that these support tools need to be open source,
> but they absolutely need to be licensed in such a way that distributions
> can repackage them and freely distribute them. I'm not aware of any
> tools currently required by cinder where this is not the case, but a few
> of us are in the process of auditing this to make sure we understand the
> situation before we clarify our rules.

I don't agree with this stance. I think the Cinder (and OpenStack) 
communities should be able to dictate what form driver take, including 
the code and the license, but when we start to try to control what 
drivers are allowed to talk to (over and API or CLI) then we are 
starting to artificially limit what kinds of storage systems can 
integrate with OpenStack.

Storage systems take a wide variety of forms, including specialized 
hardware systems, clusters of systems, pure software-based systems, open 
source, closed source, and even other SDS abstraction layers. I don't 
see the point is creating rules that specify what form a storage system 
has to take if we are going to allow a driver for it. As long as the 
driver itself and all of it's python dependencies are Apache licensed, 
we can do our job of reviewing the code and fixing cinder-level bugs. 
Any other kind of restrictions just limit customer choice and stifle 
competition.

Even if you don't agree with my stance, I see serious practical problems 
with trying to define what it and is not permitted in terms of "support 
tools". Is a proprietary binary that communicates with a physical 
controller using a proprietary API a "support tool"? What if someone 
creates a software-defined-storage system which is purely a proprietary 
binary and nothing else?

API proxies are also very hard to nail down. Is an API proxy with a 
proprietary license not allowed? What if that proxy runs on the box 
itself? What if it's a separate software package you have to install? I 
don't think we can write a set of rules that won't accidentally exclude 
things we don't want to exclude.

-Ben Swartzlander

> --
> Duncan Thomas
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>