<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 10:59 AM, Michał Jastrzębski <span dir="ltr"><<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My dear Kollegues,<br>
<br>
Today we had discussion about how to properly name/tag images being<br>
pushed to dockerhub. That moved towards general discussion on revision<br>
mgmt.<br>
<br>
Problem we're trying to solve is this:<br>
If you build/push images today, your tag is 4.0<br>
if you do it tomorrow, it's still 4.0, and will keep being 4.0 until<br>
we tag new release.<br>
<br>
But image built today is not equal to image built tomorrow, so we<br>
would like something like 4.0.0-1, 4.0.0-2.<br>
While we can reasonably detect history of revisions in dockerhub,<br>
local env will be extremely hard to do.<br>
<br>
I'd like to ask you for opinions on desired behavior and how we want<br>
to deal with revision management in general.<br><br></blockquote><div><br></div><div>I already have a change which proposes tagging images with a pbr built version [1]. I think if users want tags which are stable for the duration of a major release they should switch to using the tag specified by kolla-build.conf base_tag, which can be set to latest, ocata, pike, etc. This would leave the version tag to at least track changes to the kolla repo itself. Since the contents of upstream kolla images come from such diverse sources, all I could suggest to ensure unique tags are created for unique images is to append a datestamp to [1] (or have an extra datestamp based tag). Bonus points for only publishing a new datestamp tag if the contents of the image really changes.</div><div><br></div><div>In the RDO openstack-kolla package we now tag images with the {Version}-{Release} of the openstack-kolla package which built it[2]. I realise this doesn't solve the problem of the tag needing to change when other image contents need to be updated, but I believe this can be solved within the RDO image build pipeline by incrementing the {Release} whenever a new image needs to be published.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/448380/">https://review.openstack.org/#/c/448380/</a> </div></div>[2] <a href="https://review.rdoproject.org/r/#/c/5923/1/openstack-kolla.spec">https://review.rdoproject.org/r/#/c/5923/1/openstack-kolla.spec</a></div></div>