Open Stack

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 <sbaker at redhat.com> wrote:

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


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170418/a053b99e/attachment.html>