[Pulp-dev] Providing Pulp 3 Container Images and Installation Support

[Eric Helms]

Howdy,

A few months back, the team that handles RPM packaging for Pulp 2 (my team)
and the Pulp team got together to discuss production 'packaging' support
for Pulp 3. Where we landed was to take a container native approach from
the outset and provide installation support via the Ansible installer for
Pulp 3. This RFC aims to outline the general strategy, link to existing
work and aim towards next steps.

Note: We do not plan to provide RPMs at this time in favor of a container
native solution for deploying Pulp 3. If the user demand becomes high
enough, we'll look to discuss and collaborate on how to move forward.

Proposal

The proposal is to package Pulp 3 via containers using pypi assets as the
de-facto input source for building the container image(s). The image(s)
would be stored on https://quay.io and initially provided with support
through the ansible-pulp3 installer. The installer would pull and run the
images via systemd using podman as the default with support for Docker.
This will provide users with a singular interface for deploying and
managing Pulp 3 no matter the choice of installation (e.g. source, pypi,
containers). In the future, existing work to deploy on to Kubernetes would
be brought into the installer to support deploying the containers on top of
Kubeneretes or Openshift.

Given Pulp is a plugin based ecosystem, and images are immutable plugins
need to be handled in a user configurable way. In this space, the original
proposal was to provide enough build tooling and documentation to allow
users to re-build Pulp images with any combination of plugins they require.
The Pulp published image(s) would include a base image and at least one
image with a specific combination of plugins provided. This is an area that
has had much discussion, and ideas. Ideas such as images that deploy plugin
code to a shared volume, sidecar containers that provide plugins at
runtime, a single image with all plugins and runtime configuration and the
Discourse model of rebuilding the image locally when a plugin is added via
a commandline.

Existing Work

The existing work in this area is around two pull requests that have
provided a working proof of concept. The first is the image itself [1] and
the second is to the installer [2] that makes use of this image.

The current works' biggest design assumption (up for debate) is around a
single image vs. an image per service. The strategy difference is around a
single image that can, with the right start command, take on the role of
any Pulp 3 service. The multi-image strategy would aim to ensure there is
an image per service that knows how to properly run itself. A single image
provides a simpler build strategy to start with potentially more confusion
to users wanting to use them within their own context.

Open Questions

 * What are the communities thoughts on this approach?
 * What are the gaps to get both [1] and [2] into the respective code bases?
 * Should we stick with a single image strategy or opt to pivot to
multi-image?
 * What changes need to be made to selinux policies?
 * How is plugin support handled?

Next Steps

To move forward, I'll be looking for a Pulp maintainer to help sponsor and
shepherd this work into the Pulp ecosystem. Along with that a rough list:

 * Resolve open questions
 * Create Pulp account on quay.io
 * Add deployment support to Travis configuration
 * Get initial installer work merged

[1] https://github.com/pulp/pulp/pull/3740
[2] https://github.com/pulp/ansible-pulp3/pull/45
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190111/474d2f7d/attachment.htm>