Hi, At the the last few RDO meetings [1][2][3], we brought up that no one had stepped up to do the work to build and ship what ends up being stable TripleO containers for Pike. There was different mentions that we should bring this to the MLs but we never did, so here it is. TL;DR, Do we want stable TripleO containers ? Who's going to be building and shipping them ? Where ? - Technically speaking, the RDO project and community provides packages for installers (such as TripleO) to consume - The container images are only consumable by the TripleO project - The tooling to build containers are included in Kolla and TripleO which are packaged by RDO - There has been resistance in TripleO to adopt containers that have been built by RDO during the Pike development cycle because TripleO should be the upstream - Upstream projects, such as TripleO and Kolla, are already producing and shipping containers derived from RDO to DockerHub and tarballs.openstack.org The definition of done for shipping RDO releases [4] includes successful testing coverage of different Packstack and TripleO scenarios, the same scenarios that continuously run throughout the development cycle. I'll concede that the current definition of done (strangely) doesn't include bits around packaging -- how packages are built and shipped. It probably should and maybe this should be part of the discussion. With my RDO community hat on, I can't help but feel that it's important to keep RDO as agnostic, neutral and open as possible. We have to be careful about any bias and direct or indirect special treatment RDO might be providing to TripleO. This ensures a fair and level playing field for other projects that are interested in either using/consuming RDO or want to be included in the packaging distribution. This is what makes it easier for RDO to "grow": not just in terms of packages and contributors but in mind and market share. RDO allows operators deploy their OpenStack clouds with vanilla packages for Red Hat based distributions, no matter their software, hardware, hypervisor, drivers, backends and installer preferences. Now, back with my TripleO hat on, someone has to do the work. If we want to build and ship containers to DockerHub, we can do that already and automatically through periodic builds. The role that we have been using to build containers in RDO supports pushing to any registry, including DockerHub. If we want to build and ship containers to the CentOS official registry, "registry.centos.org", it's more work [5]. The container pipeline runs from Jenkins and builds Dockerfiles out of pseudo dist-git repositories. We would need to: - Adapt the tooling that we have to generate only Dockerfiles (~trivial) - Push them out in an organized fashion - Explicitly define the dependency and build order of the containers (complicated) It's probably also worth asking if we want to be shipping stable containers at all ? Who will be the users of those stable containers ? The tooling to build containers is included in (stable) packages provided by RDO, we have packages for Kolla and TripleO. Users will already be pushing containers to the TripleO undercloud registry, perhaps they could be expected to build the containers as well ? Let's discuss and figure out the plan moving forward. Thanks, [1]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_09/2017/rdo... [2]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_16/2017/rdo... [3]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_23/2017/rdo... [4]: https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/ [5]: https://wiki.centos.org/ContainerPipeline David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter]