As a plugin writer, I can add custom installation steps
If any plugin has special installation steps, currently there is no way to add those per plugin basis.
E.g. for RPM plugin some build dependencies should be installed before createrepo_c gets pip-installed.
#1 Updated by firstname.lastname@example.org over 1 year ago
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:
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.
#2 Updated by kersom over 1 year ago
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.
#3 Updated by email@example.com over 1 year ago
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)
#4 Updated by firstname.lastname@example.org over 1 year ago
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.
#8 Updated by bmbouter over 1 year ago
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.
#9 Updated by email@example.com over 1 year ago
bmbouter, I think that makes sense. So a playbook would be:
- hosts: all
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.
#11 Updated by firstname.lastname@example.org over 1 year ago
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.
#12 Updated by bmbouter over 1 year ago
@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
#14 Updated by ppicka over 1 year ago
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.
#15 Updated by bmbouter over 1 year ago
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?
#16 Updated by rochacbruno over 1 year ago
I have done something similar few months ago using `include_tasks`
there are some related discussion on:
#18 Updated by bmbouter over 1 year ago
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?
Please register to edit this issue