I think we have two topics and improvements here 1. images in https://hub.docker.com/r/kolla/ 2. tag in end-user env.
# images in hub.docker.com we are building kolla tag image and push them into hub.docker.com. After this, we do nothing for these images. The issue is 1. any security update is not included in these images. solution: I do not think use 4.0.0-1 4.0.0-2 in hub.docker.com is a good idea. if so, we need mark what 4.0.0-1 container and what's the difference with 4.0.0-2. This will make another chaos. And any prod env shouldn't depend on hub.docker.com's images, which is vulnerable to attack and is mutable. 2. branch images are not pushed. solution: we can add a job to push branch images into hub.docker.com like inc0 said. For example: centos-source-nova-api:4.0.0 centos-source-nova-api:ocata centos-source-nova-api:pike centos-source-nova-api:master But branch tag images is not stable ( even its name is stable/ocata ), users are not recommended to use these images # images in end-user env I recommended end user should build its own image rather then use hub.docker.com directly. in my env, I build images with following tag rule. when using 4.0.0 to build multi time, i use different tag name. For example 1st: 4.0.0.1 2nd: 4.0.0.2 3rd: 4.0.0.3 ... The advantage in this way is: keep each tag as immutable ( never override ) On Tue, Apr 18, 2017 at 6:46 AM, Steve Baker <sba...@redhat.com> wrote: > > > 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 > > > __________________________________________________________________________ > 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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me
__________________________________________________________________________ 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