Pulp

What QE is doing with pre_tasks is one way to accomplish this. It's not ideal because it needs to be configured by the user, but I don't see a better way.

Another option could be to add to the plugin variables, like this:

pulp_install_plugins:
pulp_rpm:
app_label: rpm
required_packages:
- gcc
- make

This approach is a little cleaner, but still forces each user to know the dependencies of the pulp_rpm plugin. Note that with either approach, these values may vary depending on the package manager being used by the managed node OS.

We could have variables to chose what plugin not to install, like create `defaults` pulp_rpm_install: yes, then this could be overwritten doing the playbook call.

ansible-playbook -vvv -i 192.168.122.138 -u root source-install-plugins.yml -e pulp_rpm_install no

This will give more control over what it will be installed.

Not sure if this kind of solution was discussed before.

My 2 cents:

• The user shouldn't have to know about these things (or even that an additional playbook is required) The user needing to know anything other than 'i want plugin X' is asking too much.
• Few plugins will require this (maybe i'm wrong?)
• Its okay if there is plugin specific stuff in this module (structure it to make this easy to contribute to)

From my experiences, I'll offer up two approaches for plugin writers:

1) Treat ansible-pulp3 as the canonical source for installation and have plugin writers contribute storing all plugin enablement and install in the main pulp3 role
2) Create a role for every plugin and allow simple composition. Plugin writers can contribute their role to the repository itself or publish it independently to be included.

Flexibility can lead to complexity so I caution erring on the side providing a well-defined method more so than a flexible method for plugin authors at the outset.

The issue I see with custom plugin steps being added to ansible-pulp3 itself is that we won't be able to handle version changes since ansible-pulp3 can't be versioned with plugin.

Say in plugin foo 0.1 you have to run 'thiscommand' but with 0.2 you have to run 'thatcommand'. The current version of the installer have both so someone is going to end up broken.

For this reason, I believe having the plugin provide a custom role and playbook that calls ansible-pulp3 is the easiest and most viable solution.

bmbouter, I think that makes sense. So a playbook would be:

- hosts: all
roles:
- pulp-rpm-presteps
- pulp-database
- pulp-workers
- pulp-resource-manager
- pulp-webserver
- pulp-content

Importantly, the pulp-rpm-presteps role would not be included in the ansible-pulp repository, and would be an entirely separate project.

Seems like this means there isn't really anything the installer needs to do other than suggest a role and/or pretasks as a documentation story.

@asmacdo what you are describing sounds right.

This plan is fine for running ansible playbooks directly, but there is still a gap for pulplift, which doesn't allow the user to run a custom playbook before provisioning.

Maybe we could create a new directory of pretasks, and the user could configure which pretasks to include?

For example, as-is, a developer will still have to include custom pretasks (https://github.com/PulpQE/pulp-qe-tools/blob/master/pulp3/install_pulp3/source-install-plugins.yml#L26-L44) in a the playbook (https://github.com/pulp/pulplift/blob/master/playbooks/source-install.yml#L11), which is checked into git, so not ideal.

@asmacdo, I see what you are saying.

What about having the rpm aspects install in pulplift using a post_install playbook? https://github.com/theforeman/forklift/#post-install-playbooks

What about to keep role (or just playbook) with dependencies inside pulp_rpm repository (what I understood we want) and in installer (https://github.com/pulp/ansible-pulp/blob/master/roles/pulp/tasks/install.yml#L112 e.g. above this line) got something like

when: pulp_install_plugins.pulp_rpm is defined

and if true call the playbook from rpm repository. This possibly can avoid conflict in plugin versions and user from adding any pre-task or manually edit dependencies.

ppicka, +1 to what you are proposing here.

We should probably start with getting that extra 'rpm install' role into the pulp_rpm repo and then we can add that line here to call it during install time.

I think one of us should pick this up soon to work on it. What do you think?

I have done something similar few months ago using `include_tasks`

there are some related discussion on:

https://github.com/pulp/ansible-pulp/pull/51/files

ppicka how are you going to have it install the dependencies for Pulp RPM?

After thinking about it I think we should have them install via the rpms available to Fedora and RHEL. This will limit RPM to only running on those distros but from what I'm hearing about libmodulemd not running on other distros I think it's unavoidable at this point.

dalley does this sound right to you also?