Pulp

I started implementing this: https://github.com/pulp/pulp-operator/pull/26

But stopped due to time, and needing to focus more narrowly on setting content_origin: https://github.com/pulp/pulp-operator/pull/27

My thinking around this story is that we would deploy an nginx with a mounted configmap volume. https://kubernetes.io/docs/concepts/configuration/configmap/#configmaps-and-pods

This config map would provide the ./nginx.conf and ./nginx-cfg/*.conf files https://catalog.redhat.com/software/containers/rhel8/nginx-114/5ba0ada65a134643ef2eebcc

If we want to allow for some flexibility here the custom resource would need to have a section for the proxy where a config map could be mounted. Then that information would just be used during the deployment.

Automation hub current specifies the following: https://github.com/cutwater/automation-hub-deploy

The question I have here is what would the default nginx config look like? Some entries to pulp-api and pulp-content?

I believe single container is the simplest example, We have a basic nginx.conf, and we include everything in pulp dir: https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf#L75

each plugin has its own snippet and we move it to nginx: https://github.com/pulp/pulp-oci-images/blob/latest/pulp/Containerfile#L25

as an example, here is the pulp_ansible snippet: https://github.com/pulp/pulp_ansible/blob/master/pulp_ansible/app/webserver_snippets/nginx.conf

Chris, very good idea.

Just note that the snippets canonically live in the plugins though, files within pip packages installed on the pulp container image. And the pulp-operator upstream will have many different possible plugins with different snippets. Do you have a strategy for getting them into the configmap?

And yeah, what Fabricio pointed to.

So from what I'm reading there isn't an existing image for the web server. There isn't anything in quay: https://quay.io/organization/pulp

So from the default experience we should decide what we'd want to deliver for pulp-operator upstream. I see 2 options: A) Use nginx default with the a config map only mounting https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf with no plugins B) Create a container similar to the CI containers that installs all the plugins and again mounting a config map with the nginx snippets for the used plugins

The CRD would have a proxy section with an image attribute and the volume mount mentioned above.

The image attribute would allow consumers to provide their nginx container where the pulp plugin has been installed; upstream via pip; downstream via rpm.

Thoughts?

FYI, the nginx conf we provide on pulp_installer is more complex: https://github.com/pulp/pulp_installer/blob/master/roles/pulp_webserver/templates/nginx.conf.j2

I think if we decide to have something "usable" as fast as we can, I would go with option B and the simpler nginx conf we have at https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf

I particularly vote for going simple for now and addressing requests from users in the future

chambridge wrote:

So from what I'm reading there isn't an existing image for the web server. There isn't anything in quay: https://quay.io/organization/pulp

Correct, we haven't implemented it yet.

Quay has images built as part of pulp-operator's tree https://github.com/pulp/pulp-operator/tree/main/containers

So from the default experience we should decide what we'd want to deliver for pulp-operator upstream. I see 2 options: A) Use nginx default with the a config map only mounting https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf with no plugins B) Create a container similar to the CI containers that installs all the plugins and again mounting a config map with the nginx snippets for the used plugins

The CRD would have a proxy section with an image attribute and the volume mount mentioned above.

The image attribute would allow consumers to provide their nginx container where the pulp plugin has been installed; upstream via pip; downstream via rpm.

Thoughts?

Let's go with B. Base the container image on the image used to build the all-4-services "pulp" image. An additional layer with the webserver.