[cinder] Deprecating driver versions

Erlon Cruz sombrafam at gmail.com
Mon Jul 1 11:44:30 UTC 2019


Hi Jay,

No problem. I just wanted to know if other vendors/maintainers shared the
same problems
and concerns we have and if we could have an uniform solutions across all
drivers which
is not the case.

Erlon

Em sáb, 29 de jun de 2019 às 15:19, Jay S. Bryant <jungleboyj at gmail.com>
escreveu:

> Erlon,
>
> I appreciate the goal here but I agree with Gorka here.
>
> The drivers are the vendor's responsibilities and they version them as
> they wish.  I think updating the devref some best practices
> recommendations would be good and maybe come to agreement between the
> cores on what the best practices are so that we can try to enforce it to
> some extent through reviews.  That is probably the best way forward.
>
> Jay
>
> On 6/28/2019 2:50 AM, Gorka Eguileor wrote:
> > On 27/06, Erlon Cruz wrote:
> >> Hey folks,
> >>
> >> Driver versions has being a source of a lot of confusions with
> costumers.
> >> Most of our drivers
> >> have a version number and history that are updated as the developers
> adds
> >> new fixes and
> >> features. Drivers also have a VERSION variable in the version class that
> >> should be bumped by
> >> developers. The problem with that is:
> >>
> >>     - sometimes folks from the community just push patches on drivers,
> and
> >> its hard to bump
> >>       every vendor version correctly;
> >>     - that relies in the human factor to remember adding it, and usually
> >> that fails;
> >>     - if we create a bugfix and bump the version, the backport to older
> >> branches will carry the
> >>       version, which will not reflect the correct driver code;
> >>
> >> So, the solution I'm proposing for this is that we use the Cinder
> >> versions[1] and remove all
> >> version strings for drivers. Every new release we get a version. For
> stable
> >> versions, from time to
> >> time the PTL bumps the stable version and we have an accurate ways to
> >> describe the code.
> >> If we need to backport and send something to the costumer, we can do the
> >> backport, poke
> >> the PTL, and he will generate another version which can be downloaded on
> >> github or via PIP,
> >> and present the version to our costumers.
> >>
> >> So, what are your thought around this? Anyone else has had problems with
> >> that? What would
> >> be the implications of removing the driver version strings?
> >>
> >> Erlon
> >>
> > Hi Erlon,
> >
> > I am personally against removing the drivers versions, as I find them
> > convenient and think they are good practice.
> >
> > A possible solution for the driver versioning is for a driver to
> > designate a minor version per OpenStack release and use the patch
> > version to track changes.  This way one can always backport a patch and
> > will just need to increase the patch version in the backport patch.
> >
> > Maybe we can have this formally described in our devref.   We tell
> > driver developers they can do whatever they want with the versioning in
> > master, but backports must not backport the version as it is and instead
> > increase the patch version.
> >
> > What do you think?
> >
> > If I remember correctly there are some drivers that only increase the
> > version once per release.
> >
> > Cheers,
> > Gorka.
> >
> >> [1] https://releases.openstack.org/teams/cinder.html
> >> [2]
> >>
> https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L237
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190701/7f34c105/attachment.html>


More information about the openstack-discuss mailing list