Open Stack

On 10/31/2016 02:23 PM, Sean McGinnis wrote:
> Last Tuesday we had a cross-project session around the use of proprietary
> code/libs/binaries in OpenStack drivers. The challenge we are running into
> is where to draw the line with these drivers. What is the appropriate policy
> to have in place to allow/disallow certain approaches.
>
> There was a lot of good discussion and input from multiple projects that are
> affected by this. I won't attempt to recap the full conversation here. The
> etherpad with the notes from the discussion can be found here:
>
> https://etherpad.openstack.org/p/ocata-xp-proprietary-drivers
>
> The two main concerns I heard were around 1) the ability to package and
> redistribute everything needed to run an OpenStack environment, and 2) the
> value these drivers bring to the OpenStack project. Particularly those that
> have no business logic in the code in OpenStack and just call out to third
> party libraries to handle all business logic.
>
> Proposals
> =========
>
> Option 1:
>
> - All libraries imported by the driver must be licensed such that they are
>   redistributable by package maintainers.
> - Existing non-compliant driver code would need to be updated by the Q
>   release to stay in tree.
> - Code that does not get imported into the driver at runtime (CLIs, external
>   binaries, remote application servers) are acceptable to be not
>   redistributable.
>
> Issues:
>
> - The desire for having things redistributable was to have everything fully
>   functional "out of the box" no matter how the deployer configured the system.
>   I don't believe this is ever possible. With requirements of setting up some
>   type of application or management server to enable some solutions, it is not
>   possible to package all required code and binaries for every configuration.
>
>
> Option 2:
>
> - Remove all drivers that are not completely open source and contained in the
>   project repo.
>
> Issues:
>
> - This restricts things down to only the drivers that can currently be run in
>   gate.
> - This would be a big issue for many Cinder drivers and I'm sure most Ironic
>   drivers.
> - I strongly believe this would result in less vendor involvement in upstream
>   work.
>
>
> Option 3:
>
> - Require the majority of business logic is in the open source code.
> - Allow third party, non-redistributable libraries and CLIs that are used as
>   more of an "RPC" type interface.
> - Reviewers should be able to review the driver code and at least get some
>   idea of the steps the driver is doing to perform each requested operation.
>
> Issues:
>
> - Does not address the desire to package all needed requirements.
>
>
>
> My preference is actually option 3. The reality is, with most vendor solutions
> there's always going to be some part of the overall solution that is
> proprietary and requires some configuration and setup by the deployer.
> Arbitrarily drawing that line such that a proprietary app server is OK, but a
> proprietary library is not OK, just leads to poor solution architectures such
> as requiring the end user to set up a separate server just so the driver can
> SSH into it to run commands.
>
> The case that instigated this discussion for me was a proposal to have a driver
> that did nothing more than make a one line call of everything out to a library
> that handled all logic. In that case, there is no benefit to the community of
> being able to review the code and give some assurance that it is doing things
> correctly. And the only benefit really it gives the vendor is they have an out
> of tree driver that gets advertised as being in tree.
>
> My desire as a code reviewer and project maintainer is that I can take a look
> at a driver and at least get an idea of what they are doing and how their
> device works to perform some of these operations. That's not an exact number -
> I'm not saying something like 10% of the code needs to be in the driver, but
> 9% would not be acceptable - but we need to have some visiblity to the logic
> so we as a community can at least help point users in the right direction if
> they come looking for help.
>
> I think this works for Cinder and probably is necessary for Ironic.
>
> I'd be interested in hearing feedback or other options from other folks. I'd
> especially like to hear from Helion, OSP, Mirantis, and others that are doing
> packaging and support for these deployments to hear how this impacts the way
> they do things.

As usual I'd like to point to the Linux project as a good example for 
how to handle such things. Linux is older than us and has been dealing 
with drivers and proprietary code for a very long time.

Linux does a few specific things that I like a lot:
1) Drivers have to match the license (GPLv2 in Linux's case) which 
guarantees the code is free software.
2) Drivers have to be in tree, which makes it easier for kernel 
developers to evolve the driver interfaces without breaking most drivers.
3) Drivers which require proprietary stuff (typically called "firmware" 
or "binary blobs" in the Linux world) can contribute that stuff to the 
linux-firmware repo which supports closed-source but 
freely-distributable software.

Personally I think the needs of the distros could be met with something 
like the linux-firmware repo. It would create a way for vendors that 
require proprietary stuff to make it available for distros to do what 
they need to do.

Regarding drivers that "cheat" and put all the important logic outside 
the open source driver code, I think we can safely ignore these. These 
drivers hurt nothing but themselves by hiding their logic. The chance of 
breaking them with a change to the driver interface is higher but this 
is a GOOD thing -- it discourages what we perceive to be bad behavior. 
The Linux community has already fought this battle and while some 
companies continue to supply out of tree drivers, the process is 
typically very painful for those maintainers and it motivates them to 
eventually open source their drivers and put them in the tree.

-Ben

> Thanks!
>
> Sean (smcginnis)
>
> __________________________________________________________________________
> 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
>