[cinder] Deprecating driver versions
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
[1] https://releases.openstack.org/teams/cinder.html [2] https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidf...
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/solidf...
Hi Gorka,
Em sex, 28 de jun de 2019 às 04:50, Gorka Eguileor geguileo@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.
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidf...
[1] https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/...
What driver versions are we discussing? If I look at reference [1] https://releases.openstack.org/teams/cinder.html it does not list any driver. But does have versions of componenets of cinder. Usually people refer to https://docs.openstack.org/cinder/latest/reference/support-matrix.html for drivers.
Driver versions and useful. I many case the driver version corresponds to storage backend version which makes it easier for correlate which driver needed (and version of OpenStack) for specific function support.
Each driver has a maintainer and it is maintainer responsibility to handle visioning. Expect that any driver change must get +2 from driver maintainer.
Agree with Gorka than some process documentation will be helpful Thanks, Arkady
-----Original Message----- From: Gorka Eguileor geguileo@redhat.com Sent: Friday, June 28, 2019 2:50 AM To: Erlon Cruz Cc: openstack-discuss@lists.openstack.org Subject: Re: [cinder] Deprecating driver versions
[EXTERNAL EMAIL]
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
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, andits 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/solidf...
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@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.
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidf...
participants (4)
-
Arkady.Kanevsky＠dell.com
-
Erlon Cruz
-
Gorka Eguileor
-
Jay S. Bryant