<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12.0pt; line-height:1.3; color:#1F497D">
<div>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.<br>
<br>
thx,<br>
britt<br>
</div>
<div><br>
</div>
</div>
<div id="x_quoted_header" style="clear:both">
<hr style="border:none; height:1px; color:#E1E1E1; background-color:#E1E1E1">
<div style="border:none; padding:3.0pt 0cm 0cm 0cm"><span style="font-size:11.0pt; font-family:'Calibri','sans-serif'"><b>From:</b> Paul Bourke <paul.bourke@oracle.com><br>
<b>Sent:</b> Apr 19, 2017 6:28 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [kolla] Tags, revisions, dockerhub<br>
</span></div>
</div>
<br type="attribution">
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">I'm wondering if moving to using docker labels is a better way of
<br>
solving the various issue being raised here.<br>
<br>
We can maintain a tag for each of master/ocata/newton/etc, and on each <br>
image have a LABEL with info such as 'pbr of service/pbr of kolla/link <br>
to CI of build/etc'. I believe this solves all points Kevin mentioned <br>
except rollback, which afaik, OpenStack doesn't support anyway. It also <br>
solves people's concerns with what is actually in the images, and is a <br>
standard Docker mechanism.<br>
<br>
Also as Michal mentioned, if users are concerned about keeping images, <br>
they can tag and stash them away themselves. It is overkill to maintain <br>
hundreds of (imo meaningless) tags in a registry, the majority of which <br>
people don't care about - they only want the latest of the branch <br>
they're deploying.<br>
<br>
Every detail of a running Kolla system can be easily deduced by scanning <br>
across nodes and printing the labels of running containers, <br>
functionality which can be shipped by Kolla. There are also methods for <br>
fetching labels of remote images[0][1] for users wishing to inspect what <br>
they are upgrading to.<br>
<br>
[0] <a href="https://github.com/projectatomic/skopeo">https://github.com/projectatomic/skopeo</a><br>
[1] <a href="https://github.com/docker/distribution/issues/1252">https://github.com/docker/distribution/issues/1252</a><br>
<br>
-Paul<br>
<br>
On 18/04/17 22:10, Michał Jastrzębski wrote:<br>
> On 18 April 2017 at 13:54, Doug Hellmann <doug@doughellmann.com> wrote:<br>
>> Excerpts from Michał Jastrzębski's message of 2017-04-18 13:37:30 -0700:<br>
>>> On 18 April 2017 at 12:41, Doug Hellmann <doug@doughellmann.com> wrote:<br>
>>>> Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200:<br>
>>>>> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann <doug@doughellmann.com><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34 -0700:<br>
>>>>>>> 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>
>>>>>>> Cheers,<br>
>>>>>>> Michal<br>
>>>>>>><br>
>>>>>><br>
>>>>>> What's in the images, kolla? Other OpenStack components?<br>
>>>>><br>
>>>>><br>
>>>>> Yes, each image will typically contain all software required for one<br>
>>>>> OpenStack service, including dependencies from OpenStack projects or the<br>
>>>>> base OS. Installed via some combination of git, pip, rpm, deb.<br>
>>>>><br>
>>>>>> Where does the<br>
>>>>>> 4.0.0 come from?<br>
>>>>>><br>
>>>>>><br>
>>>>> Its the python version string from the kolla project itself, so ultimately<br>
>>>>> I think pbr. I'm suggesting that we switch to using the<br>
>>>>> version.release_string[1] which will tag with the longer version we use for<br>
>>>>> other dev packages.<br>
>>>>><br>
>>>>> [1]https://review.openstack.org/#/c/448380/1/kolla/common/config.py<br>
>>>><br>
>>>> Why are you tagging the artifacts containing other projects with the<br>
>>>> version number of kolla, instead of their own version numbers and some<br>
>>>> sort of incremented build number?<br>
>>><br>
>>> This is what we do in Kolla and I'd say logistics and simplicity of<br>
>>> implementation. Tags are more than just information for us. We have to<br>
>><br>
>> But for a user consuming the image, they have no idea what version of<br>
>> nova is in it because the version on the image is tied to a different<br>
>> application entirely.<br>
><br>
> That's easy enough to check tho (just docker exec into container and<br>
> do pip freeze). On the other hand you'll have information that "this<br>
> set of various versions was tested together" which is arguably more<br>
> important.<br>
><br>
>>> deploy these images and we have to know a tag. Combine that with clear<br>
>>> separation of build phase from deployment phase (really build phase is<br>
>>> entirely optional thanks to dockerhub), you'll end up with either<br>
>>> automagical script that will have to somehow detect correct version<br>
>>> mix of containers that works with each other, or hand crafted list<br>
>>> that will have 100+ versions hardcoded.<br>
>>><br>
>>> Incremental build is hard because builds are atomic and you never<br>
>>> really know how many times images were rebuilt (also local rebuilt vs<br>
>>> dockerhub-pushed rebuild will cause collisions in tags).<br>
>>><br>
>>>> Doug<br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>