Single Organization on resources to simplify taxonomies

The current taxonomy model is very hard to understand for both Users and Developers, which in turn complicates life for both.

Even during the primary design [1], there were many arguments for a simpler model. There was even an followup RFC to change this to the said simpler model afterwards best summarized in Ivan’s comment on that [2]. We even have user feedback on the topic e.g. [3].

Every time we try to introduce a new resource/entity, we have a hard time figuring out how it fits with our existing multi-tenancy models. It’s also more complicated by the fact that some resources belong to a single Organization and Location (Host) while some others belong to multiple (Subnet, Domain). Some only support single Organization multi-tenancy but not Location at all (all Katello resources). Some ignore the multitenancy completely (Operating System). When you have a more complex object that combines other resources, it’s causing a lot of problems (e.g. Host living in org 1 being assigned to org-less OS, assigned to the subnet available in 3 orgs, being assigned LCE from a single Org but no Loc etc). Also with Katello, orgs can no longer be nested, while in non-katello installations Organizations can be nested in a tree structure, so Host in fact belongs to multiple organizations.

I’d like to propose a way out of that. In my current effort I need to have Ansible roles taxable at least by Organization so I’m proposing to start implementing this new model in Foreman Ansible, but I’d love to take it into the Foreman core for all the resources.

The proposal: Organizations should be the only taxonomy with a strict single organization per resource restriction and location would be only a classification, but not a multi-tenancy source.

This is a simple proposal that would have to be properly designed and thought through. Though the steps in my mind are:

  • Identify resources that can have multiple organizations assigned for no reason and simplify that by forcing a single organization (Hostgroup would be the first in Foreman core)
  • Identify resources that need to be shared across the organizations and figure a way to do so (keeping the current model would be the easiest) but need to be limited to only resources that has to be shared.
  • Consider dropping Organizations nesting, to get rid of multi-tenancy of models completely
  • Making location only a classification - remove Location from RBAC, stop enforcing its selection and stop filtering by it in default scope and permission checks

As this was discussed many times, I’d appreciate it if you raise blockers and thoughts to this plan in general and try not to deep dive into the implementation design yet, as I’ll have a thread once we’d start the design of each step where we can discuss implementation details.

[1] Organization/Location
[2] https://community.theforeman.org/t/rfc-replace-taxonomy-with-true-relationships-for-organizations-and-locations/4946/5
[3] Organizations and locations

4 Likes

I will reach out to a Red Hat customer where I am only doing Icinga who has probably the most complicated scenario here. Lets see if this can identify blockers with simplified taxonomies.

From other customers and environments:

  • Locations as classification should totally be fine, nesting is here nice but not necessary
  • Organisations are great for different customers or departments, if you need both nesting is great but it could be done in other ways for sure

So I think the idea is good as it simplifies development and perhaps also the user workflows and at least t does not limit the user.

2 Likes

For the record, I agree with the proposed end goal. I can see how hard it may be to get there, but I can find enough examples to justify the change. I see you posted this in Development, would it make sense to cross post or change the tag so that also users see that? I think their use-cases will be crucial when we enter the design phase and talk about what/how to share some resources in the future.

I suspect it will depend on the specific model.

For example, a host group is a concept that really represents organization without Foreman - there is nothing “out there” that it reflects. That means it’s probably easy to have one organization per host group.

However, a subnet reflects something “real” and can be shared. Let’s say you have an organization where there’s a shared 192.0.2.0/24 where all customers without their own subnet run their machines. If you have an organization for each customer, then you can’t model this. Also remember that on the Smart Proxy side there are no taxonomies and that free IP checking relies on a correct view.

Similarly, a Smart Proxy can also be shared. For example, a Puppet CA may be shared between customers in the same way as a subnet.

There may be some implications, such as that now the organization + name become unique rather than just the name. In some places our API allows querying by name (also in the URL).

So it’ll really depend on each model.

I also agree that this is more like an RFC. Any objections to moving it there?

I would definitely take it further:

  • Make organization a single taxonomy for all resources
  • Make location only a classification
  • All resources must have exactly one organization assigned (no exception like OS or Subnet)
  • No Any Organization context - users have to select an organization after login

In the new model, nothing would be shared. Meaning, more than one organizations could create the very same domain, subnet or operating system. It makes a lot of sense, say there are two organizations A and B and both want to create example.com domain and subnet 192.168.1.0. We have this concept of “sharing” in current Foreman and I think it is a bad design.

And administrator should be able to deploy smart proxies for both A and B organizations, register them and org admins/users should be able to define their own networks, domains or OSes in an independent manner.

See, the two orgs can have the same domains, but they need to have two separate DNS backend systems to manage them. Same for subnet. These would be two idependent networks. Now, I understand that there might be a use case when two organization would share the same infrastructure - but then they need to operate under a single organization and only use location to classify resources.

This will work well with Katello as well, I believe this is exactly what Katello does - every Product, Repository, Content View must have an organization assigned. If anything is shared, then its on the backend level (Pulp will not redownload the same packages).

I got answer today and it looks like there is not so much complexity, just the high amount of organizations was what the consultant who built it “scared”. There are about 40 organizations used to separate the different business units and it seems to slow down the system.

So lets assume simplifying the taxonomies will result in the same amount or only some more organizations. I would also assume simpler means also better performance, so it should be fine but this number can give us a nice edge case for testing.

1 Like

How would that work? Unless you do weird things, there can only be a single nameserver that serves example.com. The same with a subnet.

A single DNS/DHCP server can be managed by two or more smart proxies with some limitations.