<div dir="ltr"><div dir="ltr"><div>Thank you for this. I put some responses inline. Does it make any sense to put this well written proposal (and its updates over time) into a wiki page?  <a href="https://pulp.plan.io/projects/pulp/wiki/">https://pulp.plan.io/projects/pulp/wiki/</a></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_9106680068327645669gmail_attr">On Fri, Jan 11, 2019 at 1:27 PM Eric Helms <<a href="mailto:ehelms@redhat.com" target="_blank">ehelms@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Howdy,<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Proposal</div><div><br></div><div>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 <a href="https://quay.io" target="_blank">https://quay.io</a> 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.</div></div></div></div></div></blockquote><div>This sounds consistent with the discussions at PulpCon. +1 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>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. <br></div></div></div></div></div></blockquote><div>I think having all the software built into one image would be the simplest. Making it really easy for a user to pick what they want, and to get that rebuilt over time would be valuable. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Existing Work</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></div></blockquote><div>If a more complicated build system makes for a simpler deployment experience I think that's a win, so I'm +1 for the multi-image approach. If it's too much to do right now I would understand that too.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Open Questions</div><div><br></div><div> * What are the communities thoughts on this approach? <br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * What are the gaps to get both [1] and [2] into the respective code bases?</div></div></div></div></div></blockquote><div>I will look at reviewing these today/tomorrow ot give some initial feedback <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * Should we stick with a single image strategy or opt to pivot to multi-image?</div></div></div></div></div></blockquote><div>+1 for multi, but that is my opinion</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * What changes need to be made to selinux policies?</div></div></div></div></div></blockquote><div>We have no selinux policy atm so none. When we need one we can do that.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * How is plugin support handled?</div></div></div></div></div></blockquote><div>This ticket epic describes that each plugin could choose to ship a container w/ just their plugin code on top of core. Each plugin could add that to the "master" pipeline that core maintains via PRs, which sounds sustainable. Another option is to have each plugin "replicate" the code from [1] into their own repos. That sounds unmaintainable. Suggests are welcome.  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Next Steps</div><div><br></div><div>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:</div><div><br></div><div> * Resolve open questions <br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * Create Pulp account on <a href="http://quay.io" target="_blank">quay.io</a></div></div></div></div></div></blockquote><div>I made  a pulp account for us to ship the images with.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * Add deployment support to Travis configuration</div></div></div></div></div></blockquote><div> Let's IRC collab so I can make the encrypted Travis secret for your PR. Where in the Travis config does it go?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> * Get initial installer work merged</div></div></div></div></div></blockquote><div>Yes, let's. I'm going to look at it.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>[1] <a href="https://github.com/pulp/pulp/pull/3740" target="_blank">https://github.com/pulp/pulp/pull/3740</a></div><div>[2] <a href="https://github.com/pulp/ansible-pulp3/pull/45" target="_blank">https://github.com/pulp/ansible-pulp3/pull/45</a></div></div></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div></div></div>