Open Stack

Hi Gorka,

Em sex, 28 de jun de 2019 às 04:50, Gorka Eguileor <geguileo at redhat.com>
escreveu:

> 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.
>

How do you usually see people using that? And what makes that convenient
for you?
I see that they would  be a good practice if the were properly updated and
reflected the
code status. For example the rbd.py driver. Has used the same version
(1.2.0) since Ocata[1].
I can tell that is the same for most of our drivers.


> 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.
>

We would again have to rely on developers doing the right thing, and things
will be the same as they are today. The point here is to have a reliable
way to
version the code .


> What do you think?
>

One thing we could do to still is to link the drivers version to a function
that get the release version. Something like:

MyDriver(){
    VERSION = utils.get_current_version()
    ...
}

But we could also do a fancy logic that would get the vendor proposed
version and bump it automatically.

MyDriver(){
    VERSION = '1.2.0'
    VERSION = utils.bump_version()
    ...
}

Where bump_version() would always use the current openstack version to know
what version the driver should be.


> 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


[1]
https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/rbd.py
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190628/13368b78/attachment-0001.html>