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. > 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