Open Stack

Kolla's general target is in the node range of 1 - 100 nodes. A lot of smaller clusters can't afford to do ci/cd of their own and so Kolla currently pushes all the work to the site, and the site can't afford to do it right, and so just doesn't deal with security updates.

This is akin to a site forcing super secure passwords and so all the users just write the password on a sticky note and put it under their keyboard. The ideal is extra security, but the reality is less security.

Keeping up to date containers with security updates applied  and trackable helps solve a real issue. I agree, it is better to do it at your own site, if you can afford it, but like most things security, its not a bool, secure or not, its a spectrum. Providing tagged up to date images on the hub strengthens the security of a lot of openstacks.

It also lowers the hugely high bar of getting a production system workable. You don't have to build all the containers from the get go to get a system going. You can do that as you get time to do so.

Thanks,
Kevin

________________________________
From: Jeffrey Zhang [zhang.lei.fly at gmail.com]
Sent: Monday, April 17, 2017 7:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

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<http://hub.docker.com>

we are building kolla tag image and push them into hub.docker.com<http://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<http://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<http://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<http://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<http://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<mailto:sbaker at redhat.com>> wrote:


On Tue, Apr 18, 2017 at 9:57 AM, Doug Hellmann <doug at doughellmann.com<mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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