deduplicate systemd config examples with the ansible-pulp templates
The templates in our docs here ( https://docs.pulpproject.org/en/3.0/nightly/installation/instructions.html#systemd ) could instead refer the users to the pulp-ansible templates. We could have the user link to the ansible-pulp templates for the three systemd files they should be deploying:
These should also link to the variable definitions, e.g. https://github.com/pulp/ansible-pulp/blob/master/roles/pulp/README.md#role-variables
systemd docs use Ansible Installer Template
The systemd docs were incomplete in various ways and regularly out of
date. This rewrites that section to link users to the Ansible
Installer's templates for these files which are maintained and will be
up to date.
#2 Updated by firstname.lastname@example.org 7 months ago
The only problem with doing this today is that the templates are in jinja, and the user may not understand where the variables are set in ansible-pulp. (For instance, pulp_install_dir default is set in the pulp role, even though the template is defined in the pulp-worker (or other processes that you mentioned) role.
If we do link to the template, we should also link to the documentation that specifies the value's meaning and default. https://github.com/pulp/ansible-pulp/blob/master/roles/pulp/README.md#role-variables
This plan might actually make more sense than rendering the template with default values, since they might not align with what the user has installed.
- Description updated (diff)
@asmacdo linking to their definitions I think will make this very clear for users. I edited it to include the linking to the definitions.
What about the default should we document those?
Also is taking away these copy/paste versions going to be a problem for our users?
#4 Updated by email@example.com 7 months ago
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
I think we should not document the default, since it is already duplicated in ansible-pulp (where the default is set, and in the README).
IMO, the users not being able to copy/paste is acceptable. If they are using the default values and want this to be "out of the box", they should use ansible-pulp. If they are setting up their config to be custom, then they won't benefit from default values.
#8 Updated by firstname.lastname@example.org 7 months ago
I just want to point out that another option is to install static .service files (containing both static settings and default settings) under /usr/lib/systemd/system/ , and put the customized settings as systemd override files like /etc/systemd/system/<service-name>/<arbitrary-name>.conf .
I'm not sure of PyPI can install & maintain the files under /usr/lib/systemd/system/ (RPM can), but this would simplify keeping the manual instructions & ansible-pulp in sync. All you'd need to do is specify the customized settings in both.
I believe with the PyPI packages we can't assume the user will be using systemd so I don't think we can deliver the unit files as part of PyPI. for example we don't ship dependencies on database drivers for he same reason, because we can't know if they want to use mysql or postgresql.
The installer can install the systemd files correctly because it knows specifically if the system should use systemd or not.
- Status changed from MODIFIED to POST
Moving back to post so I can make one more PR that describes the pulp-api content service configuration need.
This should fix up: https://www.redhat.com/archives/pulp-list/2019-April/msg00026.html
Please register to edit this issue