[openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?
Steven Dake (stdake)
stdake at cisco.com
Wed May 17 15:17:20 UTC 2017
There has been a lot of cost and risk analysis in this thread.
What hasn’t really been discussed at great detail is the “benefit analysis” which you have started. I think we are all clear on the risks and the costs.
If we as a technical community are going to place a line in the sand and state “thou shall not ship containers to dockerhub” because of the risks inherent in such behavior, we are not integrating properly with the emerging container ecosystem. Expecting operators to build their own images is a viable path forward. Unfortunately, the lack of automation introduces significant cognitive load for many (based upon the Q&A in the #openstack-kolla channel on a daily basis). This cognitive load could be (incorrectly) perceived by many to be “OpenStack doesn’t care about integrating with adjacent communities.”
On balance, the benefits to OpenStack of your proposal outweigh the costs.
From: Michał Jastrzębski <inc007 at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Wednesday, May 17, 2017 at 7:47 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?
On 17 May 2017 at 04:14, Chris Dent <cdent+os at anticdent.org> wrote:
> On Wed, 17 May 2017, Thierry Carrez wrote:
>> Back to container image world, if we refresh those images daily and they
>> are not versioned or archived (basically you can only use the latest and
>> can't really access past dailies), I think we'd be in a similar situation
> Yes, this.
I think it's not a bad idea to message "you are responsible for
archving your containers". Do that, combine it with good toolset that
helps users determine versions of packages and other metadata and
we'll end up with something that itself would be greatly appreciated.
Few potential user stories.
I have OpenStack <100 nodes and need every single one of them, hence
no CI. At the same time I want to have fresh packages to avoid CVEs. I
deploy kolla with tip-of-the-stable-branch and setup cronjob that will
upgrade it every week. Because my scenerio is quite typical and
containers already ran through gates that tests my scenerio, I'm good.
I have 300+ node cloud, heavy CI and security team examining every
container. While I could build containers locally, downloading them is
just simpler and effectively the same (after all, it's containers
being tested not build process). Every download our security team
scrutinize contaniers and uses toolset Kolla provides to help them.
Additional benefit is that on top of our CI these images went through
Kolla CI which is nice, more testing is always good.
And another one
We are Kolla community. We want to provide testing for full release
upgrades every day in gates, to make sure OpenStack and Kolla is
upgradable and improve general user experience of upgrades. Because
infra is resource constrained, we cannot afford building 2 sets of
containers (stable and master) and doing deploy->test->upgrade->test.
However because we have these cached containers, that are fresh and
passed CI for deploy, we can just use them! Now effectively we're not
only testing Kolla's correctness of upgrade procedure but also all the
other project team upgrades! Oh, it seems Nova merged something that
negatively affects upgrades, let's make sure they are aware!
And last one, which cannot be underestimated
I am CTO of some company and I've heard OpenStack is no longer hard to
deploy, I'll just download kolla-ansible and try. I'll follow this
guide that deploys simple OpenStack with 2 commands and few small
configs, and it's done! Super simple! We're moving to OpenStack and
start contributing tomorrow!
Please, let's solve messaging problems, put burden of archiving on
users, whatever it takes to protect our community from wrong
expectations, but not kill this effort. There are very real and
immediate benefits to OpenStack as a whole if we do this.
> Chris Dent ┬──┬◡ﾉ(° -°ﾉ) https://anticdent.org/
> freenode: cdent tw: @anticdent
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev