<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 8:12 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">So after discussion started here [1] we came up with something like that:<br>
<br>
1. Docker build will create "fingerprint" - manifesto of versions<br>
saved somewhere (LABEL?)<br></blockquote><div><br></div><div>This would be great, especially a full package version listing in an image label. However I don't see an easy way of populating a label from data inside the image. Other options could be:</div><div>- have a script inside the image in a known location which generates the package manifest on the fly, do a docker run whenever you need to get a manifest to compare with another image.</div><div>- write out the package list during image build to a known location, do a docker run to cat out its contents when needed</div><div><br></div><div>As for the format, taking a yum only image as an example would we need anything more than the output of "rpm -qa | sort"?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. We create new CLI tool kolla-registry for easier management of<br>
pushing and versioning<br>
3. kolla-registry will be able to query existing source docker<br>
registry (incl. dockerhub) for latest tag-revision and it's version<br>
manifesto, also dest registry for tags-revisions and manifesto<br>
4. if source image manifesto != dest image manifesto -> push source<br>
image to dest registry and increase tag-revision by 1<br>
5. kolla-registry will output latest list of images:tags-revisions<br>
available for kolla-k8s/ansible to consume<br>
6. we keep :4.0.0 style images for every tag in kolla repository.<br>
These are static and will not be revised.<br>
<br></blockquote><div><br></div><div>Yes, this is fine, but please keep in mind that this change[1] could be merged without changing these published 4.0.0 style image tags, with the added advantage of locally built images with a git checkout of kolla have a less ambiguous default tag.</div><div> </div><div>[1] <a href="https://review.openstack.org/#/c/448380/">https://review.openstack.org/#/c/448380/</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Different scenerios can be handled this way<br>
1. Autopushing to dockerhub will query freshest built registry<br>
(tarballs, source) and and dockerhub (dest), it will create<br>
image:branchname (nova-api:ocata) for HEAD of stable branch every run<br>
and image:branchname-revision with revision increase<br>
2. Users will have easy time managing their local registry - dockerhub<br>
(source) and local (dest), if nova-api:ocata on dockerhub is newer<br>
than local, pull it to local and increase local tip and revision<br>
<br>
Thoughts?<br></blockquote><div><br></div><div>Generally positive :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2017-04-19.log.html#t2017-04-19T19:10:25" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/irclogs/%23openstack-<wbr>kolla/%23openstack-kolla.2017-<wbr>04-19.log.html#t2017-04-19T19:<wbr>10:25</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On 19 April 2017 at 10:45, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
> That works for detecting changes in the build system.<br>
><br>
> It does not solve the issue of how to keep containers atomic on end user systems.<br>
><br>
> All images in a k8s deployment should be the same image. This is done by specifying the same tag. When a new update is done, the updated deployment should specify a new tag to distinguish it from the old tag so that roll forwards/roll backs work atomically and as designed. Otherwise, roll back can actually break or roll forward wont actually grab newer images.<br>
><br>
> Thanks,<br>
> Kevin<br>
><br>
> ______________________________<wbr>__________<br>
> From: Michał Jastrzębski [<a href="mailto:inc007@gmail.com">inc007@gmail.com</a>]<br>
> Sent: Wednesday, April 19, 2017 8:32 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub<br>
><br>
> I think LABEL is great idea for all the "informative" stuff. In fact<br>
> if we could somehow abuse LABEL to fill it up after we get packages<br>
> installed, we could use it for version manifesto. That will make logic<br>
> around "if version changed" much easier since we'll have easy access<br>
> to this information on both image and container.<br>
><br>
> Our autopushing mechanism will work with tags and HEAD of stable<br>
> branch in this case.<br>
><br>
> Kevin, then your use case would be done like that:<br>
> 1. pull container nova-compute:ocata, tag it locally to<br>
> nova-compute:ocata-deployed, deploy it<br>
> 2. every now and then pull fresh nova-compute:ocata from dockerhub<br>
> 3. compare versions in LABELs to see whether you want to upgrade or not<br>
> 4. if you do, retag :ocata-deployed to :ocata-old, :ocata to<br>
> :ocata-deployed and run upgrade<br>
> 5. keep ocata-old, revision it, backup it for as long as you want<br>
><br>
> I also think that we can ship utils to do this in kolla, so people<br>
> won't need to write these themselves.<br>
><br>
> Does that work?<br>
><br>
> Cheers,<br>
> Michal<br>
><br>
> On 19 April 2017 at 05:02, Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br>
>> On 19/04/17 11:20 +0100, Paul Bourke wrote:<br>
>>><br>
>>> I'm wondering if moving to using docker labels is a better way of solving<br>
>>> 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 to CI<br>
>>> of build/etc'. I believe this solves all points Kevin mentioned except<br>
>>> rollback, which afaik, OpenStack doesn't support anyway. It also solves<br>
>>> people's concerns with what is actually in the images, and is a standard<br>
>>> 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 they're<br>
>>> 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, functionality<br>
>>> which can be shipped by Kolla. There are also methods for fetching labels of<br>
>>> remote images[0][1] for users wishing to inspect what they are upgrading to.<br>
>>><br>
>>> [0] <a href="https://github.com/projectatomic/skopeo" rel="noreferrer" target="_blank">https://github.com/<wbr>projectatomic/skopeo</a><br>
>>> [1] <a href="https://github.com/docker/distribution/issues/1252" rel="noreferrer" target="_blank">https://github.com/docker/<wbr>distribution/issues/1252</a><br>
>><br>
>><br>
>><br>
>> You beat me to it, Paul.<br>
>><br>
>> I think using lables to communicate the version of each openstack software<br>
>> installed in the image is the way to go here. We're looking into doing this<br>
>> ourselves as part of the RDO pipeline and it'd be awesome to have it being<br>
>> part<br>
>> of kolla-build itself. Steve Baker, I believe, was working on this.<br>
>><br>
>> The more explicit we are about the contents of the image, the better. People<br>
>> want to know what's in there, rather than assuming based on the tag.<br>
>><br>
>> Flavio<br>
>><br>
>><br>
>>> -Paul<br>
>>><br>
>>> On 18/04/17 22:10, Michał Jastrzębski wrote:<br>
>>>><br>
>>>> On 18 April 2017 at 13:54, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>>>>><br>
>>>>> Excerpts from Michał Jastrzębski's message of 2017-04-18 13:37:30 -0700:<br>
>>>>>><br>
>>>>>> On 18 April 2017 at 12:41, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Excerpts from Steve Baker's message of 2017-04-18 10:46:43 +1200:<br>
>>>>>>>><br>
>>>>>>>> On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann<br>
>>>>>>>> <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>><br>
>>>>>>>>> Excerpts from Michał Jastrzębski's message of 2017-04-12 15:59:34<br>
>>>>>>>>> -0700:<br>
>>>>>>>>>><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<br>
>>>>>>>>>> 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<br>
>>>>>>>>>> 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<br>
>>>>>>>>>> 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>
>>>>>>>><br>
>>>>>>>> Yes, each image will typically contain all software required for one<br>
>>>>>>>> OpenStack service, including dependencies from OpenStack projects or<br>
>>>>>>>> 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<br>
>>>>>>>> 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<br>
>>>>>>>> use for<br>
>>>>>>>> other dev packages.<br>
>>>>>>>><br>
>>>>>>>> [1]<a href="https://review.openstack.org/#/c/448380/1/kolla/common/config.py" rel="noreferrer" target="_blank">https://review.openstack.<wbr>org/#/c/448380/1/kolla/common/<wbr>config.py</a><br>
>>>>>>><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>
>>>>>><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>
>>>>><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>
>>>><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>
>>>>>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>>> Unsubscribe:<br>
>>>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>>>><br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><br>
>> --<br>
>> @flaper87<br>
>> Flavio Percoco<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>