I see a possible conflict between the design of the Foreman Ansible modules and Ansible best practices on the one hand, and user expectations relating to Foreman’s multitenancy on the other.
Background: We use the Foreman Ansible modules as part of the orcharhino installer to add post installation configuration. For example, users can select from a list of operating systems (e.g.: “Ubuntu 18.04”) which will then be fully configured for provisioning with Foreman by our Ansible role. So far so good. Now consider a user who does not select “Ubuntu 18.04” during the initial installation, but now wants it. Well they could just set the relevant Ansible variable and re-run the playbook, right? In principal yes, but here the conflict with multitenancy:
Suppose the Foreman installation has Organization A and Organization B, which are managed by separate teams/departments. The Organization A administrators don’t want to use the Foreman Ansible modules, so they add “Ubuntu 18.04” by hand, via the GUI. The Organization B administrators are more automation minded, and want to do everything using the Foreman Ansible Modules, but they have no idea what Organization A is getting up to. They now want to add “Ubuntu 18.04” to their Organization, so they re-run the playbook. Since Ansible is state descriptive, and the Organization B administrators only request their own organization, this will have the effect of kicking the existing “Ubuntu 18.04” entities (created by Organization A via the GUI) out of Organization A.
This will probably make Organization A very angry.
Diagnosis: It follows, that as soon as anyone wants to use the Foreman Ansible Modules to manage Foreman, everyone must use Foreman Ansible Modules for everything (or risk fighting each other). Surely, this clashes with basic user expectation of Foreman’s promise of multitenancy?
- Don’t pretend Organizations/Locations provide multitenancy since entities are shared across taxonomies and conflicts are inevitable?
- Completely rework the way Organizations/Locations work?
- Add a option to the Foreman Ansible modules to be additive (rather than state descriptive) with respect to Organizations/Locations (a mitigation at best, and totally counter to Ansible design principles).
- Explain to me why the use case I described, and/or my whole understanding of Foreman’s multitenancy support is wrong/invalid?!
I am pretty sure @evgeni will have some opinions on this, but I would love to here from as many community members as possible!
P.S.: I don’t really have much skin in this particular debate myself. I am perfectly happy to have somebody explain to me why the use case I described/my understanding of multitenancy is nonsense. In that case I wonder if there is some documentation I missed (or still needs to be written).