Open Stack

On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>> >>
>> >> As follow up on the mailing list discussion [0], gerrit activity
>> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
>> >> discussion how Cinder follows, or rather does not follow, the standard
>> >> deprecation policy [4] as the project has been tagged on the assert
>> >> page [5].
>> >>
> <snip>
>> >>
>> >> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
>> >> [1] https://review.openstack.org/#/c/348032/
>> >> [2] https://review.openstack.org/#/c/348042/
>> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>> >> [4] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
>> >> [5] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
>> >>
>> >
>> > Can you be more specific about what you mean? Are you saying that
>> > the policy isn't being followed because the drivers were removed
>> > without a deprecation period, or is there something else to it?
>> >
>> > Doug
>> >
>>
>> Yes, that's how I see it. Cinder's own policy is that the drivers can
>> be removed without any warning to the consumers while the standard
>> deprecation policy defines quite strict lines about informing the
>> consumer of the functionality deprecation before it gets removed.
>>
>> - Erno
>
> It is a good point. I think it highlights a common thread though with
> the other discussion that, at least so far, third party drivers are
> treated differently than the rest of the code.
>
> For any other functionality we certainly follow the deprecation policy.
> Even in existing drivers we try to enforce that any driver renames,
> config setting changes, and similar non-backwards compatible changes go
> through the normal deprecation cycle before being removed.
>
> Ideally I would love it if we could comply with the deprecation policy
> with regards to driver removal. But the reality is, if we don't see that
> a driver is being supported and maintained by its vendor, then that
> burden can't fall on the wider OpenStack and Cinder community that has
> no way of validating against physical hardware.
>
> I think third party drivers need to be treated differently when it comes
> to the deprecation policy. If that is not acceptable, then I suppose we
> do need to remove that tag. Tag removal would be the lesser of the two
> versus keeping around drivers that we know aren't really being
> maintained.
>
> If it came to that, I would also consider creating a new cinder-drivers
> project under the Cinder umbrella and move all of the drivers not tested
> by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> would try to avoid that if possible. But it would at least allow us to
> still get code reviews and all of the benefits of being in tree. Just
> some thoughts.
>
> Sean
>

Sean,

As said on my initial opening, I do understand and agree with the
reasoning/treatment of the 3rd party drivers. My request for that tag
removal is out of the remains of my ops hat.

Lets say I was ops evaluating different options as storage vendor for
my cloud and I get told that "Here is the list of supported drivers
for different OpenStack Cinder back ends delivered by Cinder team", I
start looking what the support level of those drivers are and see that
Cinder follows standard deprecation which is fairly user/ops friendly
with decent warning etc. I'm happy with that, not knowing OpenStack I
would not even look if different subcomponents of Cinder happens to
follow different policy. Now I buy storage vendor X HW and at Oct I
realize that the vendor's driver is not shipped, nor any remains of it
is visible anymore, I'd be reasonably pissed off. If I knew that the
risk is there I would select my HW based on the negotiations that my
HW is contractually tied to maintain that driver and it's CI, and that
would be fine as well or if not possible I'd select some other
solution I could get reasonably guarantee that it will be
supported/valid at it's expected life time. As said I don't think
there is anything wrong with the 3rd party driver policy, but
maintaining that and the tag about standard-deprecation project wide
is sending wrong message to those who do not know better to safeguard
their rear ends.

The other option would be to leave the drivers in tree, tag them with
deprecation message, something like "This driver has not been tested
by vendor CI since 15.3.2016 and cannot be guaranteed working. Unless
testing will be resumed the driver will be removed on Unicorn
release". Which would give as clear indication that the driver seems
abandoned, but still provide the consumer easier way to test in their
staging if the driver is something they still dare to use in
production or not.

IMHO this is purely to set the expectations right for our consumers so
that they know what to expect from us and what to demand from their
vendors. Personally I don't think such tags should be the reason why
we do development in certain way, but rather just indication for the
consumer where they should pay attention while making the decisions.

- Erno