<div dir="ltr"><div dir="ltr">Hi Gorka,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex, 28 de jun de 2019 às 04:50, Gorka Eguileor <<a href="mailto:geguileo@redhat.com">geguileo@redhat.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 27/06, Erlon Cruz wrote:<br>
> Hey folks,<br>
><br>
> Driver versions has being a source of a lot of confusions with costumers.<br>
> Most of our drivers<br>
> have a version number and history that are updated as the developers adds<br>
> new fixes and<br>
> features. Drivers also have a VERSION variable in the version class that<br>
> should be bumped by<br>
> developers. The problem with that is:<br>
><br>
> - sometimes folks from the community just push patches on drivers, and<br>
> its hard to bump<br>
> every vendor version correctly;<br>
> - that relies in the human factor to remember adding it, and usually<br>
> that fails;<br>
> - if we create a bugfix and bump the version, the backport to older<br>
> branches will carry the<br>
> version, which will not reflect the correct driver code;<br>
><br>
> So, the solution I'm proposing for this is that we use the Cinder<br>
> versions[1] and remove all<br>
> version strings for drivers. Every new release we get a version. For stable<br>
> versions, from time to<br>
> time the PTL bumps the stable version and we have an accurate ways to<br>
> describe the code.<br>
> If we need to backport and send something to the costumer, we can do the<br>
> backport, poke<br>
> the PTL, and he will generate another version which can be downloaded on<br>
> github or via PIP,<br>
> and present the version to our costumers.<br>
><br>
> So, what are your thought around this? Anyone else has had problems with<br>
> that? What would<br>
> be the implications of removing the driver version strings?<br>
><br>
> Erlon<br>
><br>
<br>
Hi Erlon,<br>
<br>
I am personally against removing the drivers versions, as I find them<br>
convenient and think they are good practice.<br></blockquote><div><br></div><div>How do you usually see people using that? And what makes that convenient for you?</div><div>I see that they would be a good practice if the were properly updated and reflected the</div><div>code status. For example the rbd.py driver. Has used the same version (1.2.0) since Ocata[1].</div><div>I can tell that is the same for most of our drivers.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A possible solution for the driver versioning is for a driver to<br>
designate a minor version per OpenStack release and use the patch<br>
version to track changes. This way one can always backport a patch and<br>
will just need to increase the patch version in the backport patch.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe we can have this formally described in our devref. We tell<br>
driver developers they can do whatever they want with the versioning in<br>
master, but backports must not backport the version as it is and instead<br>
increase the patch version.<br></blockquote><div><br></div><div><div>We would again have to rely on developers doing the right thing, and things</div><div>will be the same as they are today. The point here is to have a reliable way to</div><div>version the code .</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What do you think?<br></blockquote><div><br></div><div>One thing we could do to still is to link the drivers version to a function that get the release version. Something like:<br><br>MyDriver(){</div><div> VERSION = utils.get_current_version()</div><div> ...</div><div>}<br></div><div><br></div><div>But we could also do a fancy logic that would get the vendor proposed version and bump it automatically.</div><div><br></div><div><div>MyDriver(){</div><div> VERSION = '1.2.0'</div><div> VERSION = utils.bump_version()</div><div> ...<br></div><div>}<br></div><div><br></div></div><div>Where bump_version() would always use the current openstack version to know what version the driver should be.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If I remember correctly there are some drivers that only increase the<br>
version once per release.<br>
<br>
Cheers,<br>
Gorka.<br>
<br>
> [1] <a href="https://releases.openstack.org/teams/cinder.html" rel="noreferrer" target="_blank">https://releases.openstack.org/teams/cinder.html</a><br>
> [2]<br>
> <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L237" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L237</a></blockquote><div><br></div><div>[1] <a href="https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/rbd.py">https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/rbd.py</a></div><div> </div></div></div>