[openstack-dev] [kolla] Tags, revisions, dockerhub
Flavio Percoco
flavio at redhat.com
Tue Apr 18 14:36:18 UTC 2017
On 13/04/17 13:48 +1200, Steve Baker wrote:
>On Thu, Apr 13, 2017 at 10:59 AM, Michał Jastrzębski <inc007 at gmail.com>
>wrote:
>
>> My dear Kollegues,
>>
>> Today we had discussion about how to properly name/tag images being
>> pushed to dockerhub. That moved towards general discussion on revision
>> mgmt.
>>
>> Problem we're trying to solve is this:
>> If you build/push images today, your tag is 4.0
>> if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
>> we tag new release.
>>
>> But image built today is not equal to image built tomorrow, so we
>> would like something like 4.0.0-1, 4.0.0-2.
>> While we can reasonably detect history of revisions in dockerhub,
>> local env will be extremely hard to do.
>>
>> I'd like to ask you for opinions on desired behavior and how we want
>> to deal with revision management in general.
>>
>>
>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.
>
>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.
>
>[1] https://review.openstack.org/#/c/448380/
>[2] https://review.rdoproject.org/r/#/c/5923/1/openstack-kolla.spec
I like this option better because it's more consistent with how things are done
elsewhere in OpenStack.
Flavio
--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170418/65285338/attachment.sig>
More information about the OpenStack-dev
mailing list