Pulp

I'm worried "pulp_complete" would be confused with "complete set of plugins".

Other possible names: pulp_meta pulp_all_in_one pulp_allinone pulp_server pulp_single_server

mdepaulo@redhat.com wrote:

I'm worried "pulp_complete" would be confused with "complete set of plugins".

Other possible names: pulp_meta pulp_all_in_one pulp_allinone pulp_server pulp_single_server

From this list I like pulp_single_server and pulp_server the most. I'll also throw pulp_all_services out there too. In the future we want to have the installer provide cluster installs, what name can we select here that will help contrast against that? In the future clustered install mode we would not use this name right? If so, then having it call out "single_server" or "all_services" may be the best. Wdyt?

bmbouter wrote:

mdepaulo@redhat.com wrote:

I'm worried "pulp_complete" would be confused with "complete set of plugins".

Other possible names: pulp_meta pulp_all_in_one pulp_allinone pulp_server pulp_single_server

From this list I like pulp_single_server and pulp_server the most. I'll also throw pulp_all_services out there too. In the future we want to have the installer provide cluster installs, what name can we select here that will help contrast against that? In the future clustered install mode we would not use this name right? If so, then having it call out "single_server" or "all_services" may be the best. Wdyt?

I agree with "pulp_all_services" for those reasons. I'll start on this now.

I love this story. Yes an hundred times.

I have several comments, feel free to incorporate the one you find relevant and discard the other.

On the role separation¶

I have a small nit, I would vote in splitting the pulp_database role in two pieces.

• pulp_database (that is basically the content of install_db playbook) - And that people might feel free to not call at all.
• pulp_database_configuration (that is the migration really taking place) - That is mandatory to be run.

More on the why below

Name of the meta role¶

I would go with pulp_allinone, because really this is what it is, you call this role and you get a fully functionnal pulp system (redis, db, webserver and pulp services) up and running.

To me, pulp_all_services would be something like:

• pulp_content
• pulp_api
• pulp_resource_manager
• pulp_workers
• pulp_database_configuration

This way people can come with their pre existing services Database, Redis and Webserver and still have a fully functional pulp backend (cluster or not).

You might be wondering why I am putting webserver out of the list ? The way it is managed today pretty much impose an nginx conf with a single server. What if I am a customer with an already existing fleet of Nginx servers that are the "only" nginx my company allows us to use as proxy entrance point (we already have monitoring, ha and ops practices for those) can I just integrate it in them ?

Technically, on top of already having the role, we would simply need to provide the nginx.conf in the doc so people can integrate it (Affter modiffication) to their already running nginx and have them point at the proper backend.

I feel the two above point would make the installer gain in flexibility and also ease the way into incorporating intro an already existing IT system (where thing are already backed up, monitored and all) rather that having pulp using their own services for its needs.

spredzy wrote:

I love this story. Yes an hundred times.

:D

I have several comments, feel free to incorporate the one you find relevant and discard the other.

On the role separation¶

I have a small nit, I would vote in splitting the pulp_database role in two pieces.

• pulp_database (that is basically the content of install_db playbook) - And that people might feel free to not call at all.
• pulp_database_configuration (that is the migration really taking place) - That is mandatory to be run.

I was thinking of doing something like this as well.

More on the why below

Name of the meta role¶

I would go with pulp_allinone, because really this is what it is, you call this role and you get a fully functionnal pulp system (redis, db, webserver and pulp services) up and running.

To me, pulp_all_services would be something like:

• pulp_content
• pulp_api
• pulp_resource_manager
• pulp_workers
• pulp_database_configuration

This way people can come with their pre existing services Database, Redis and Webserver and still have a fully functional pulp backend (cluster or not).

I plan to introduce another meta role that includes that set as well.

I was leaning against pulp_allinone because it kind of implies all plugins.

Someone else pointed out that "pulp_all_services" makes sense because we refer to everything as a service, including the database. As an SOA.

I'm thinking of naming the meta role for those 5 "pulp_services".

You might be wondering why I am putting webserver out of the list ? The way it is managed today pretty much impose an nginx conf with a single server. What if I am a customer with an already existing fleet of Nginx servers that are the "only" nginx my company allows us to use as proxy entrance point (we already have monitoring, ha and ops practices for those) can I just integrate it in them ?

Very good point. I am aware of this. It is a big deal for the kubernetes operator (pulp-operator).

Technically, on top of already having the role, we would simply need to provide the nginx.conf in the doc so people can integrate it (Affter modiffication) to their already running nginx and have them point at the proper backend.

Yeah, this is a problem for the kubernetes operator. generic k8s ingresses don't support it, or even the prior set of features we needed before the snippets (probably). The solution (for now, when I resume work on it) is to have Pulp's own webserver, and the kubernetes ingresses in front of it.

I feel the two above point would make the installer gain in flexibility and also ease the way into incorporating intro an already existing IT system (where thing are already backed up, monitored and all) rather that having pulp using their own services for its needs.

Agreed, I'll do them in separate PRs/issues though (the outstanding PR is getting harder to merge everytime another PR is merged.)

PR: https://github.com/pulp/pulp_rpm/pull/1756