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 <inc...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <firstname.lastname@example.org> Date: Wednesday, May 17, 2017 at 7:47 AM To: "OpenStack Development Mailing List (not for usage questions)" <email@example.com> 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...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev