How do you use Foreman organizations/locations?

Hello everyone,

@ezr-ondrej wrote a proposal outlining the complexities that surround the current Foreman organization / location taxonomies and his hopes to simplify this.

It would be of great help to the future design if we could gather community use cases to consider. The more people we hear from, the more we can factor your scenarios into any future development.

In general, it would be great if you could reply to this thread with an overview of your setup. In general, I would also like to know your opinion on Foreman’s organization and location taxonomies. Is it serving your scenarios well? Has it caused you pain at times?

If you’re struggling with where to begin in summarizing your use case, here are a few questions that might serve as icebreakers.

  • How many organizations do you use in your Foreman deployment?
  • Which resources are shared across several organizations?
  • Can you imagine not sharing resources or is that necessary for you?
  • Do you use nested organizations?

Could you merge Location and Organizations to the single entity in your use case (Organization as the only entity, locations would remain only as a tag for easy filtering)

If you don’t feel comfortable posting publicly, you are welcome to write to me privately also!

3 Likes

Hi,

thanks for starting the discussion! :slight_smile:

I’m working as a consultant and often do installations and trainings for customers. Most customers are confused when creating and managing resources at the beginning because of taxonomy complexity (e.g. created a hostgroup in the wrong context). Beside the Host/Content Host separation, most customers told me that they find having multiple organizations and locations too complex at all in the beginning.

I totally agree with this. I’m also using Uyuni/SUSE Manager quite a lot where you only have organizations as top-level taxonomy - most customers find this easier. I have no customer that makes use of nested organizations and locations. It’s a nice to have but I don’t see a common use-case.

Most customer installations I do look like this:

  • one Foreman/Katello host
  • one Foreman proxy running Pulp (for larger installations where I want to keep the Pulp load from the main server)
  • Foreman proxies per remote locations (if required)

Usually remote locations have a dedicated location in the same organization. Most of my customers don’t require dedicated organizations for multi-tenancy - I only had a few installations where this was needed. Most resources that are shared between organizations are network and DNS information - not sharing resources might be a drawback for some users, I think.

Just my 2 cent - might not apply to bigger customer sites. Hope this helps a little bit.

Best wishes,
Christian.

6 Likes

I can agree with all of this.

While I have also some bigger customers not many really need taxonomy at all, but some make use of it. I already asked some to share information here, but some examples from my mind.

Our managed service team used Foreman before switch to Openstack and they gave also customers access to Foreman, so Organization was used to differentiate the customers and Location was used to differentiate the data centers. Organization was used to separate users and hosts, all other resources were shared.

A customer uses Locations to separate datacenters and office network in the same organization, so it is used to limit hosts to the correct smart proxy for DNS, DHCP, …

Another one uses Organizations to mirror internal organizational structure, first level is the company and second the department. I think but I am not sure most resources are shared here at least between departments and not so much between companies.

A similar approach by another one uses Organizations for the companies but locations for the department.

So I fear what we can learn of this is we gave users a flexible solution and they use it for good or bad. Being more opinionated here would make life easier, but will likely need some (careful) changes on existing setups.

6 Likes

Hi,

on our site, we originally started with only one organization and one location, like most people seem to.
We later added a second organization just to handle some trouble we had with how subscriprion-manager and candlepin reacted to the presence of “special purpose” subcription for things like OpenShift. We were struggling with those subscriptions randomly being handet to standard RHEL servers or their hypervisors, which are the majority of our datacenter, and wanted those special subscriptions to be tucked away so we would not have juggle subscrions around permanently.
Recently, we added a third organization for windows servers only, to ensure the windows people can only see and work with windows related things and the other way around for the linux folks.

Concerning locations, we are now also at a total of 3, with the additional locations resembling logiically distinct parts of our datacenter (you can think of this like “internal datacenter network” and DMZ). Apart from filtering purposes, we also use this distinction for assigning the correct smart-proxies, compute resources, etc.

We have never had a use-case for nesting anything in this area (and probably never will).

Concerning sharing of resources, we use this feature quite a lot. We share everything between both organizations and locations that is possible and does not need to differ. Probably our biggest pain-point in this regard is that resource sharing is somewhat inconsistent in a lot of areas. There are some things that must be shared (like operating systems and their settings), some things that can not be shared (at least between organizations) like anything content related, and finally things that can optionally be shared (like hostgroups) but might break at one point or another because they can contain references to things that are not or cannot be shared.

In our use-case, I could imagine merging the organizations and doing the good old “Windows vs Linux” thing through location filtering. But that would require a working solution for our candlepin/subman problem, since I do not feel like rearranging a lot of subscriptions on a regular basis ever again.
Having locations merged would probably also work, but would require us to blow our already bloated host-group structer up even more, probably resulting in even more redundant data in many of them. This possibly could be solved with a major rethinking of how we use hostgroups, but by now we did not really have time to invest into this department despite the fact it is probably needed, but that’s a different problem :wink:

If you want more info on any of these areas, feel free to DM me and I will see what I can provide :slight_smile:

6 Likes

Hi all,

I’m with everything I’ve read so far :wink: so far so good! And I’m just adding my 2ct to the discussion on how I manage Foreman (and by extension also Satellite) environments. Note: all of the things below concern small (<50 hosts) environments. Sometimes in a bigger enterprise network, but as somewhat of an island.

I’m with @stdevel , the installations I did are mostly the same as well. Though for the installs I did, it was not a proxy remote location, but a proxy per security/lifecycle zone.

And as @Dirk also mentioned, the current solution is very flexible, but it can also make your life complex when used wrong.

Now to answer the questions more directly:

  1. All environments I’ve built so far (all different customers) have 1 organization. Mainly because they wanted to have all Linux machines use Foreman as the central repo. For our own Foreman (we run a managed services team) we actually do use locations, as they are a more lightweight way to split groups of hosts. Locations allow us to still share all repos, host groups etc, but we can still target the hosts accurate enough using Ansible and the Foreman Inventory plugin.
  2. N/A
  3. As I have limited experience (only when doing the Satellite training I used it :wink: ) on multi-tenancy with organizations, I can’t add anything useful with regards to sharing resources…
  4. No :slight_smile:
  5. I’m not sure, I think so yes. I’ll try to sketch the working situation we have in our MST:
    – We have 1 organization (admin) which holds all of the repos, host groups etc.
    – Each client has their own location within Admin. Machines for each client are joined using a Activation key for that client/host group combination
    – We create a Foreman user for each client, which only has access to a single location. We use that user for Ansible when running plays against those clients machines.

Final note, these are very small clients (less then 5 machines, but they still want a bit more control over what patches are pushed when)

Hope this helps :wink:

3 Likes

Thanks a lot for a great write ups everyone!

Would you say that strict filetring per location is also necessary? E.g. user assigned to loc Boston can’t see loc Paris resources. Or could location be more like a tag, allowing just easy searching or filtering, e.g. search all hosts with “location = Paris”

Were the users not concerned with the fact one org users could overwrite DNS records or DHCP reservations of another org when resources are shared? Were they aware of this implication?

The smart proxy is typically set on subnet or domain level (sometimes on host level too, depends on feature). Was the location used to limit what is available at subnet/domain form drop down? Or how did it help with the separation?

I totally agree. Would you say the described scenarios couls be achieved with a single taxonomy class, e.g. Organization only? Assuming sharing was still possible.

Also @Dirk I’d like to hear your thoughts on the first two questions too.

Very informative! Would you say that the OS should be taxable? Or would you end up sharing them cross multiple orgs? Would there be an example of a resource which is today taxable but you always end up sharing it cross all orgs (effectively ignoring taxability of that resource, we have semi-working checkbox for that in org/loc edit form)

Does that mean using some “admin” role for everyone and assigning the location to the user? Or do you clone admin role for every location and set the location for such role?

1 Like

No, we only create these users so Ansible can select the hosts that are part of that location. The user itself only has view permissions. The clients we serve with this instance don’t have an interest in logging in to Foreman itself.

Now that you mentioned this, it originally started as a limitation in the Foreman Ansible plugin (IIRC) where it was not possible to select hosts that have a specific location. I just opened the docs again, but you’ve already added that in the plugin.

Which kind of renders the point of the user moot :slight_smile:

1 Like

Having strict filtering as an option would definitely be nice - e.g. to limit users only to their appropriate “home location”. Currently this needs to be manually with hostgroups and custom roles - don’t get me wrong, it’s possible but it’s way more effort to implement IMHO.

Good point - never stumbled upon this issue at customer installations. But you’re right - this might vary for other users.

This might be due to my lack of knowledge concerning how assigning templates to an operatiing system actually works, but since templates are taxable and operatingsystems are not, you can very easily end up in a situation where you have disfunctional operatingsystems in an organization (location too, for that case) because it is systemwide configured to use templates that are not accessible within certain taxonomies. Also, it just adds to the confusion around this topic that OSes are not taxable imo.

I just checked and in fact we do not have a single resource type we share across all organizations and locations. Once some things currently in development are finished, we will probably end up sharing all our Puppet environments across everything, but that’s about it. I think having templates not taxable might be a thing to look at because I cannot imagine a reason you would want to tax those, but I might just not be seeing how other people use this feature. Use having them taxed is more a thing of “we can keep it looking cleaning this way” than any real usecase.

1 Like

Yes, main reason was to limit ways someone can end with an invalid combination.

I think it should work with one taxonomy and some tagging, depending on how the tagging works (but do not take it for granted if some customers or others disagree).

In most environments a filter in the role would be enough, but roles are another thing tending to get complicated.

As long as it is the same DNS or DHCP server with same domain and subnet in the end, this could also happen in other ways and it would not be clear for the (Foreman) admin that it is shared. And if this is not the case, there is no reason to share Domain and Subnet.

1 Like