Open Stack

I think we need to meet the following:

 1. provide up to date containers including if the dependencies changed without the main package changed.
 2. trackable changes. If a dep in a container changed, the tag should be different. This allows users to know that something changed.
 3. atomic changes. The version on their system now vs the new version should be easily separable so roll forward/rollback is supported in case something goes wrong.
 4. minimal changes. The revision should be bumped only if something did change, not just was rebuilt but nothing changed.
 5. tested changes. The gate jobs should be run to successful completion before released.

With this arrangement, and with a similar arrangement for helm package revisioning, the user can:

helm upgrade --name nova-compute kolla/nova-compute

And if any of the containers changed, it will perform a rolling upgrade.

Something that can be easily put in a cron job and should have minimal impact.

:ocata or 4.0.0 doesn't meet #2 and #3. I'm ok with having those tags in addition to revisions to support folks that dont want to follow the pattern above. In that case, they would just point to the newest revision.

Thanks,
Kevin

________________________________________
From: Michał Jastrzębski [inc007 at gmail.com]
Sent: Monday, April 17, 2017 8:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

So, while I agree that everyone should use images built locally, I
also see what is value of downloading dockerhub-hosted images (besides
speed). Images at dockerhub passed our gates and are CI tested. Which
means quality of these images is ensured by our CI. Not everyone can
afford to have CI/CD system in their infra, so for small/medium
installation this actually might be more stable than local builds.

Given that both local and dockerhub hosted images have valid
production use case, I'd like that we keep our tagging mechanism same
for both.
That makes revisions per se impossible to handle (4.0.0-3 on dockerhub
doesn't mean 4.0.0-3 locally). Also how often we push 4.0.0-x? Daily
for quickest update on security patches (preferably for me), that
would mean that our dockerhub registry would grow extremely fast if
we'd like to retain every revision. One idea would be to put a little
of this weight on users (sorry!). We could upload daily :ocata images
and delete old ones. I think not many people does daily openstack
upgrades (cool use case tho), that means they will have some stale
:ocata image locally. We can just put an expectation to backup your
images locally, ones that you actually use. Just tar.gz
/var/lib/docker/volumes/registry/_data and save it somewhere safe.
Then you can always come back to it.

Bottom line, my suggestion for now is to have schema like that:

image-name:4.0.0 -> corresponding docker tag and image built (pref
automatically) close to tagging date
image-name:ocata -> tip of ocata branch build daily - the freshest
code that past gates
image-name:master -> tip of master branch

To achieve fully repeatable builds, we would need to have 4.0.0 type
tagging (based on pbr+git tag), version manifesto generation (as
discussed on PTG) and mechanism to consume existing manifestos and
rebuild images with these exact versions (baring issues with repo
removing previous version...). That is quite a project in it's own...

Thoughts?

Cheers,
Michal

On 17 April 2017 at 19:43, Jeffrey Zhang <zhang.lei.fly at gmail.com> wrote:
> 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
>
> __________________________________________________________________________
> 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
>

__________________________________________________________________________
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