Pulp

I agree that this probably the least undesirable solution.

However:
1. We are going to have document these settings in pulpcore, but tell users to specify them when running ansible-pulp.
2. Users are going to have to specify them in a .yml file. Because specifying them as command-line args to ansible-playbook is too messy. We already do this by default for variables, but now it is infeasible to specify them by hand on the command-line.
3. In which git repo are we going to include an example or default dictionary file?

mdepaulo@redhat.com wrote:

I agree that this probably the least undesirable solution.

However:
1. We are going to have document these settings in pulpcore, but tell users to specify them when running ansible-pulp.

Each setting will need to be documented in the pulpcore docs. For the installer though, I imagined the description of the pulp_settings variable would allow the user to know how to build the dictionary.

2. Users are going to have to specify them in a .yml file. Because specifying them as command-line args to ansible-playbook is too messy. We already do this by default for variables, but now it is infeasible to specify them by hand on the command-line.

I see what you're saying about making it easy to express them. Will there be problems in taking a yaml settings file and making it Python? Since we auto-choose Python as the format for the settings file the installer is producing, maybe the user should just provide the settings.py file itself?

3. In which git repo are we going to include an example or default dictionary file?

We struggled with settings file defaults in Pulp2 because the actual defaults in the code and the documented defaults were regularly out of date. From that experience my main takeaway is that rather than having the defaults "supplied" at runtime, just have them in Pulp itself and have users only think about how they want to change those defaults. This also avoids problems from newer setting in Pulp and having to merge new 'default' files with your already customized version over and over again. Does this make sense?

I'd recommend against a large dictionary as it makes it hard to override just one setting. Can you point me in the code where this is being done? (I'll try to suggest something better)

bmbouter wrote:

mdepaulo@redhat.com wrote:

I agree that this probably the least undesirable solution.

However:
1. We are going to have document these settings in pulpcore, but tell users to specify them when running ansible-pulp.

Each setting will need to be documented in the pulpcore docs. For the installer though, I imagined the description of the pulp_settings variable would allow the user to know how to build the dictionary.

They'd probably want to modify a file with it instead of using the default/example file.

2. Users are going to have to specify them in a .yml file. Because specifying them as command-line args to ansible-playbook is too messy. We already do this by default for variables, but now it is infeasible to specify them by hand on the command-line.

I see what you're saying about making it easy to express them. Will there be problems in taking a yaml settings file and making it Python?

No, this isn't the problem.

Since we auto-choose Python as the format for the settings file the installer is producing, maybe the user should just provide the settings.py file itself?

That might be simpler, yeah.

3. In which git repo are we going to include an example or default dictionary file?

We struggled with settings file defaults in Pulp2 because the actual defaults in the code and the documented defaults were regularly out of date. From that experience my main takeaway is that rather than having the defaults "supplied" at runtime, just have them in Pulp itself and have users only think about how they want to change those defaults. This also avoids problems from newer setting in Pulp and having to merge new 'default' files with your already customized version over and over again. Does this make sense?

Ahh, right, I forgot about that.

I guess if by default Pulp users never override these vars, then that makes sense.

So here's what your proposal will look like if a user wanted to specify 3 settings:
you would see the file:
https://github.com/pulp/ansible-pulp/blob/master/example-source/group_vars/all
And at the end, the user would add a dictionary variable like:

pulp_app_settings:
  setting1: value1
  setting2: value2
  setting3: value3

Now, there are features of Ansible to put this variable in another .yml file rather than this one. Probably one that just looks like:

setting1: value1
setting2: value2
setting3: value3

However, say the user wants to specify it on the command-line.

Instead of specifying:

ansible-playbook  example-use/playbook.yml  -e setting1="value1"  -e setting2="value2"  -e setting3="value3"

You would have to override the entire dictionary, with proper JSON (or YML) syntax:

ansible-playbook  example-use/playbook.yml  -e "pulp_app_settings":{ "setting1": "value1", "setting2":"value2", "setting3":"value3" }'

Those double quotes may not all be necessary, but still.

I literally forgot a double-quote as I originally wrote that command.

@mikedep333 those examples all look great to me. I can include those examples formats in the README section on this variable to provide clear examples.

I want to finalize the details around pulp_secret_key. That is the only required setting Pulp users must set. The installer has it today and uses it. So what is better?

1. Keep pulp_secret_key separate and have custom jinja logic that ensures pulp_secret_key is used even if 'secret_key' is specified via 'pulp_settings'?

2. Don't do anything special and make pulp_settings a required setting with at a minimum the 'secret_key' value?

I think I lean towards option 2 because it's "less custom logic so that would be less-surprising for users.

+1 to Option 2. I like the idea of all settings.py vars in 1 place.

amacdona@redhat.com wrote:

+1 to Option 2. I like the idea of all settings.py vars in 1 place.

I don't think there are 2 options.

I think the 2-item-list is the 2 parts of the same solution.

Mike, oops, didn't mean to be ambiguous. Both parts of the solution in the description +1.

My comment about option 2 was how to deal with the pulp secret. https://pulp.plan.io/issues/5031#note-5

https://github.com/pulp/ansible-pulp/pull/125