Yes. within a stable branch, the kolla code hardly ever changes. but nova may put out a new release, or openssl may put out a new release. ________________________________________ From: Michał Jastrzębski [inc...@gmail.com] Sent: Tuesday, April 18, 2017 9:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub
Our issue is a bit complex tho. Dockerhub-pushed images are less affected by version of our code than versions of everyone else's code. On 18 April 2017 at 07:36, Flavio Percoco <fla...@redhat.com> wrote: > On 13/04/17 13:48 +1200, Steve Baker wrote: >> >> On Thu, Apr 13, 2017 at 10:59 AM, Michał Jastrzębski <inc...@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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev