settingsLogin | Registersettings

[openstack-dev] [TripleO] What's the plan for shipping Pike TripleO containers ?

0 votes

Hi,

At the the last few RDO meetings 13, 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 ?

From my perspective, RDO is in kind of a weird spot:
- 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,

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 30, 2017 in openstack-dev by dms_at_redhat.com (3,780 points)   3 4

2 Responses

0 votes

On 29.08.2017 17:58, David Moreau Simard wrote:
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 ?

From my perspective, RDO is in kind of a weird spot:
- 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 ?

I believe it'd be OK to ship only the stable packages to build images
from... Just one note that the build and promote pipeline shall become
the part of the shipped product as well.

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 ?

That's a good assumption IMO. Given that there is the openstack-kolla
tools to build, the tripleo-common kolla override template, and the
packages to build from, we could allow the product users to build
containers. The quality of the target images will be a function of the
quality of the used packages only, either from RDO or
other/upstream/downstream mirrors.

Let's discuss and figure out the plan moving forward.

Thanks,

[1]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_09/2017/rdo_meeting___2017_08_09.2017-08-09-15.00.log.html#l-207
[2]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_16/2017/rdo_meeting___2017_08_16.2017-08-16-15.00.log.html#l-33
[3]: http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_08_23/2017/rdo_meeting___2017_08_23.2017-08-23-15.00.log.html#l-194
[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]


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 29, 2017 by bdobreli_at_redhat.c (2,260 points)   2 3
0 votes

snip
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 ?
snip

My 2cts as a consumer of “just” RDO packages and working to move to containers:
(We are currently running our own puppet infra and have something like a homegrown Triple0 (under-overcloud))

What I see us doing is building our own containers with Kolla putting as much of our own config in there except what needs to change at runtime.
Runtime stuff are mostly passwords and things depending on the region.

Some reasons for building our own containers:
* we have some home grown code to put in the pipelines of various OpenStack components
* makes for minimal configuration needed at deploy time if the container itself includes all settings
A nice bonus I see is that we can deploy from source if ever needed with Kolla.

Do note that we might not be a “standard” user in many regards as we have the skillset and time to do these things by ourselves.

Cheers,
Robert van Leeuwen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 30, 2017 by Van_Leeuwen,_Robert (1,740 points)   1 3
...