On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis <sean.mcgin...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev