Open Stack

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.

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