On Thu, Apr 20, 2017 at 8:12 AM, Michał Jastrzębski <inc...@gmail.com> wrote:
> So after discussion started here [1] we came up with something like that: > > 1. Docker build will create "fingerprint" - manifesto of versions > saved somewhere (LABEL?) > 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: - 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. - write out the package list during image build to a known location, do a docker run to cat out its contents when needed As for the format, taking a yum only image as an example would we need anything more than the output of "rpm -qa | sort"? > 2. We create new CLI tool kolla-registry for easier management of > pushing and versioning > 3. kolla-registry will be able to query existing source docker > registry (incl. dockerhub) for latest tag-revision and it's version > manifesto, also dest registry for tags-revisions and manifesto > 4. if source image manifesto != dest image manifesto -> push source > image to dest registry and increase tag-revision by 1 > 5. kolla-registry will output latest list of images:tags-revisions > available for kolla-k8s/ansible to consume > 6. we keep :4.0.0 style images for every tag in kolla repository. > These are static and will not be revised. > > 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. [1] https://review.openstack.org/#/c/448380/ Different scenerios can be handled this way > 1. Autopushing to dockerhub will query freshest built registry > (tarballs, source) and and dockerhub (dest), it will create > image:branchname (nova-api:ocata) for HEAD of stable branch every run > and image:branchname-revision with revision increase > 2. Users will have easy time managing their local registry - dockerhub > (source) and local (dest), if nova-api:ocata on dockerhub is newer > than local, pull it to local and increase local tip and revision > > Thoughts? > Generally positive :) > > [1] http://eavesdrop.openstack.org/irclogs/%23openstack- > kolla/%23openstack-kolla.2017-04-19.log.html#t2017-04-19T19:10:25 > > On 19 April 2017 at 10:45, Fox, Kevin M <kevin....@pnnl.gov> wrote: > > That works for detecting changes in the build system. > > > > It does not solve the issue of how to keep containers atomic on end user > systems. > > > > 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. > > > > Thanks, > > Kevin > > > > ________________________________________ > > From: Michał Jastrzębski [inc...@gmail.com] > > Sent: Wednesday, April 19, 2017 8:32 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub > > > > I think LABEL is great idea for all the "informative" stuff. In fact > > if we could somehow abuse LABEL to fill it up after we get packages > > installed, we could use it for version manifesto. That will make logic > > around "if version changed" much easier since we'll have easy access > > to this information on both image and container. > > > > Our autopushing mechanism will work with tags and HEAD of stable > > branch in this case. > > > > Kevin, then your use case would be done like that: > > 1. pull container nova-compute:ocata, tag it locally to > > nova-compute:ocata-deployed, deploy it > > 2. every now and then pull fresh nova-compute:ocata from dockerhub > > 3. compare versions in LABELs to see whether you want to upgrade or not > > 4. if you do, retag :ocata-deployed to :ocata-old, :ocata to > > :ocata-deployed and run upgrade > > 5. keep ocata-old, revision it, backup it for as long as you want > > > > I also think that we can ship utils to do this in kolla, so people > > won't need to write these themselves. > > > > Does that work? > > > > Cheers, > > Michal > > > > On 19 April 2017 at 05:02, Flavio Percoco <fla...@redhat.com> wrote: > >> On 19/04/17 11:20 +0100, Paul Bourke wrote: > >>> > >>> 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 > >> > >> > >> > >> You beat me to it, Paul. > >> > >> I think using lables to communicate the version of each openstack > software > >> installed in the image is the way to go here. We're looking into doing > this > >> ourselves as part of the RDO pipeline and it'd be awesome to have it > being > >> part > >> of kolla-build itself. Steve Baker, I believe, was working on this. > >> > >> The more explicit we are about the contents of the image, the better. > People > >> want to know what's in there, rather than assuming based on the tag. > >> > >> Flavio > >> > >> > >>> -Paul > >>> > >>> On 18/04/17 22:10, Michał Jastrzębski wrote: > >>>> > >>>> On 18 April 2017 at 13:54, Doug Hellmann <d...@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 <d...@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 > >>>>>>>> <d...@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-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 > >>>> > >>> > >>> ____________________________________________________________ > ______________ > >>> 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 > >> > >> > >> -- > >> @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 > > __________________________________________________________________________ > 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
