Open Stack

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.

Thanks!

Sean (smcginnis)