Open Stack

one other thing. checksums also do not relay any information about newer/older'ness. Only that a change happened.

________________________________
From: Britt Houser (bhouser) [bhouser at cisco.com]
Sent: Wednesday, April 19, 2017 3:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I agree with Paul here.  I like the idea of solving this with labels instead of tags.  A label is imbedded into the docker image, and if it changes, the checksum of the image changes.  A tag is kept in the image manifest, and can be altered w/o changing the underlying image.  So to me a label is better IMHO, b/c it preserves this data within the image itself in a manner which is easy to detect if its been altered.

thx,
britt

________________________________
From: Paul Bourke <paul.bourke at oracle.com>
Sent: Apr 19, 2017 6:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I'm wondering if moving to using docker labels is a better way of
solving the various issue being raised here.

We can maintain a tag for each of master/ocata/newton/etc, and on each
image have a LABEL with info such as 'pbr of service/pbr of kolla/link
to CI of build/etc'. I believe this solves all points Kevin mentioned
except rollback, which afaik, OpenStack doesn't support anyway. It also
solves people's concerns with what is actually in the images, and is a
standard Docker mechanism.

Also as Michal mentioned, if users are concerned about keeping images,
they can tag and stash them away themselves. It is overkill to maintain
hundreds of (imo meaningless) tags in a registry, the majority of which
people don't care about - they only want the latest of the branch
they're deploying.

Every detail of a running Kolla system can be easily deduced by scanning
across nodes and printing the labels of running containers,
functionality which can be shipped by Kolla. There are also methods for
fetching labels of remote images[0][1] for users wishing to inspect what
they are upgrading to.

[0] https://github.com/projectatomic/skopeo
[1] https://github.com/docker/distribution/issues/1252

-Paul

On 18/04/17 22:10, Michał Jastrzębski wrote:
> On 18 April 2017 at 13:54, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Michał Jastrzębski's message of 2017-04-18 13:37:30 -0700:
>>> On 18 April 2017 at 12:41, Doug Hellmann <doug at doughellmann.com> wrote:
>>>> Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200:
>>>>> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann <doug at doughellmann.com>
>>>>> wrote:
>>>>>
>>>>>> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:
>>>>>>> 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.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Michal
>>>>>>>
>>>>>>
>>>>>> What's in the images, kolla? Other OpenStack components?
>>>>>
>>>>>
>>>>> Yes, each image will typically contain all software required for one
>>>>> OpenStack service, including dependencies from OpenStack projects or the
>>>>> base OS. Installed via some combination of git, pip, rpm, deb.
>>>>>
>>>>>> Where does the
>>>>>> 4.0.0 come from?
>>>>>>
>>>>>>
>>>>> Its the python version string from the kolla project itself, so ultimately
>>>>> I think pbr. I'm suggesting that we switch to using the
>>>>> version.release_string[1] which will tag with the longer version we use for
>>>>> other dev packages.
>>>>>
>>>>> [1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py
>>>>
>>>> Why are you tagging the artifacts containing other projects with the
>>>> version number of kolla, instead of their own version numbers and some
>>>> sort of incremented build number?
>>>
>>> This is what we do in Kolla and I'd say logistics and simplicity of
>>> implementation. Tags are more than just information for us. We have to
>>
>> But for a user consuming the image, they have no idea what version of
>> nova is in it because the version on the image is tied to a different
>> application entirely.
>
> That's easy enough to check tho (just docker exec into container and
> do pip freeze). On the other hand you'll have information that "this
> set of various versions was tested together" which is arguably more
> important.
>
>>> deploy these images and we have to know a tag. Combine that with clear
>>> separation of build phase from deployment phase (really build phase is
>>> entirely optional thanks to dockerhub), you'll end up with either
>>> automagical script that will have to somehow detect correct version
>>> mix of containers that works with each other, or hand crafted list
>>> that will have 100+ versions hardcoded.
>>>
>>> Incremental build is hard because builds are atomic and you never
>>> really know how many times images were rebuilt (also local rebuilt vs
>>> dockerhub-pushed rebuild will cause collisions in tags).
>>>
>>>> Doug
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170419/9cef7a18/attachment.html>