Open Stack

Michael,

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.

Regards
-steve


-----Original Message-----
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.
    
    Another one:
    
    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.
    
    Cheers,
    Michal
    
    > --
    > 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
    > 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