Open Stack

On Fri, Aug 12, 2016 at 03:40:47PM +0300, Duncan Thomas wrote:
> On 12 Aug 2016 15:28, "Thierry Carrez" <thierry at openstack.org> wrote:
> >
> > Duncan Thomas wrote:
> 
> > I agree that leaving broken drivers in tree is not significantly better
> > from an operational perspective. But I think the best operational
> > experience would be to have an idea of how much risk you expose yourself
> > when you pick a driver, and have a number of them that are actually
> > /covered/ by the standard deprecation policy.
> >
> > So ideally there would be a number of in-tree drivers (on which the
> > Cinder team would apply the standard deprecation policy), and a separate
> > repository for 3rd-party drivers that can be removed at any time (and
> > which would /not/ have the follows-standard-deprecation-policy tag).
> 
> So we'd certainly have to move out all of the backends requiring
> proprietary hardware, since we couldn't commit to keeping them working if
> their vendors turn of their CI. That leaves ceph, lvm, NFS, drdb, and
> sheepdog, I think. There is not enough broad knowledge in the core team
> currently to support sheepdog or drdb without 'vendor' help. That would
> leave us with three drivers in the tree, and not actually provide much
> useful risk information to deployers at all.
> 
> > I understand that this kind of reorganization is a bit painful for
> > little (developer-side) gain, but I think it would provide the most
> > useful information to our users and therefore the best operational
> > experience...
> 
> In theory this might be true, but see above - in practice it doesn't work
> that way.

I was leaning towards a separate repo until I started thinking about all
the overhead and complications this would cause. It's another repo for
cores to watch. It would cause everyone extra complication in setting up
their CI, which is already one of the biggest roadblocks. It would make
it a little harder to do things like https://review.openstack.org/297140
and https://review.openstack.org/346470 to be able to generate this:
http://docs.openstack.org/developer/cinder/drivers.html. Plus more infra
setup, more moving parts to break, and just generally more
complications.

All things that can be solved for sure. I just question whether it would
be worth having that overhead. Frankly, there are better things I'd like
to spend my time on.

I think at this point my first preference would actually be to define a
new tag. This addresses both the driver removal issue as well as the
backporting of driver bug fixes. I would like to see third party drivers
recognized and treated as being different, because in reality they are
very different than the rest of the code. Having something like
follows_deprecation_but_has_third_party_drivers_that_dont would make a
clear statement that their is a vendor component to this project that
really has to be treated differently and has different concerns
deployers need to be aware of.

Barring that, I think my next choice would be to remove the tag. That
would really be unfortunate as we do want to make it clear to users that
Cinder will not arbitrarily break APIs or do anything between releases
without warning when it comes to non-third party drivers. But if that is
what we need to do to effectively communicate what to expect from
Cinder, then I'm OK with that.

My last choice (of the ones I'm favorable towards) would be marking a
driver as untested/unstable/abandoned/etc rather than removing it. We
could flag these a certain way and have then spam the logs like crazy
after upgrade to make it very and painfully clear that they are not
being maintained. But as Duncan pointed out, this doesn't have as much
impact for getting vendor attention. It's amazing the level of executive
involvement that can happen after a patch is put up for driver removal
due to non-compliance.

Sean