Problem: pulp_installer CI often fails to test more than 1 OS at a time #377
Conversation
Solution: Run pulp_database_config's block of task for each OS, disabling the run_once. Via a private variable. fixes: #7263 https://pulp.plan.io/issues/7263
|
Attached issue: https://pulp.plan.io/issues/7263 |
| @@ -36,7 +36,7 @@ | |||
| no_log: true | |||
| when: pulp_default_admin_password is defined and migrate_auth.changed | |||
|
|
|||
| run_once: true | |||
| run_once: "{{ __pulp_database_config_run_once }}" | |||
There was a problem hiding this comment.
This feels like a hack. And it does not support the installation of multiple clusters in the same go. Do you think we can limit the runs by running the tasks per database host delegated to the corresponding first api host?
https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegation
There was a problem hiding this comment.
@mdellweg hopefully, and that seems like a better solution, but:
- Right now, CI is broken and I have urgent work to do. I want to address that later.
- It seems like it requires the roles to have awareness of the inventory (host groups?), which we currently don't do as an upstream set of roles for users to consume.
- It would require role refactoring again, which is moderately time consuming.
|
I see. So this is not going to be a feature, but only a workaround for the very specific way, we test the roles. |
Yup, hence why I am prefixing the var with 2 underscores. To indicate it is private. |
The installer refers to "an installation" as singular. My understanding is that doing multiple installs at once only worked because we never did anything to interfere with it until now. I believe we should discuss this at the installer meeting. |
Solution: Run pulp_database_config's block of task for each OS,
disabling the run_once. Via a private variable.
fixes: #7263
https://pulp.plan.io/issues/7263