@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!
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.
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.
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
If you want more info on any of these areas, feel free to DM me and I will see what I can provide
I’m with everything I’ve read so far 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:
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.
N/A
As I have limited experience (only when doing the Satellite training I used it ) on multi-tenancy with organizations, I can’t add anything useful with regards to sharing resources…
No
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)
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?
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.
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.
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.
Our team is fairly small (five people), and we only have a single Foreman server for our 300 nodes. We simply need an ENC for Puppet. We don’t use Katello, but may in the future.
For our use case, Locations and Organizations are not helpful. They actually cause confusion at times, because sometimes we’ll find that some other component isn’t in the correct Location or Organization, and a team member is not able to see certain things until we correct this mistake.
We make extensive use of organizations and locations for Puppet, and/or more specifically in Hiera.
We have three (main) offices around the globe, and each office has a fair amount of different locations in their geographical region.
We don’t make use of nested Organizations, yet. We do use nesting in the Locations, there are three top level locations for each of the geographical regions and then the actual locations blow them. In total we have 3 Organizations, 3 Top level Locations, and a total of around 60 locations nested below those.
Organizations/offices can have hosts in any location in any of the geographical regions. So the relationship between Org. and Loc. is N:N. Hosts are assigned a Location based on where they or their hyper-visor is physically located and the Organization is set based on which office “owns” (or is considered primary user of, or manages) the hosts.
Our main use-case for them is to lookup Organization and Location specific values in Hiera from Puppet. e.g Puppet sets the timezone based on Organization, and things like DNS & NTP servers based on Location. Those are just the most simple/basic examples, quite a lot more customization is done based on both.
So when you ask “Could you merge Location and Organizations to the single entity in your use case”, the answer is a clear “No”. We actively use both, and both for their own distinct purposes. Losing the distinction would be another nightmare. (I’m still not completely over the removal of smart class variables.)
we have several customers using foreman/katello or orcharhino (or satellite), so we have some different setups which are affected by this.
After I read all the other posts, I can agree with stdevel, Dirk, areyus and Thulium-Drake for their experience.
Most customers have just one organization and often also only one location or several locations just for filtering, while all templates and resources are shared through all locations.
But we also have some setups, which need the difference locations or organizations. Those are only a part of the customers but usually those with large infrastructure and the maintenance of more than 1000 hosts. So to share some examples where organizations and locations are used:
organizations are used to have different departements of a big company to administer their hosts - they want to have as much as possible separated - but they have the issue, that for example OS are always shared across organizations, so they have to workaround with their specialized templates by using associations on the templates based on hostgroups
locations are often used just to filter certain datacenters or zones - in setups with many proxies, we often use a location to filter out all the hosts belonging to the katello/orcharhino setup in one dedicated location - however, just as overview or separation
locations for different datacenters often matter because they use the same subnets, which are spanned over more than one datacenter, but the subnet is created multiple times and assigned only to one location to set settings like the dns-server for the datacenter, the host is deployed in - this is some kind of logic, which could also be performed by ansible or something similar but currently this is a scenario, which developed over some time
most usecases are separation for RBAC, so that filtering for users is easy, where they have access or not - however in this aspect often the inconsitencies between the permissions of foreman and katello create issues, because sometimes it is hard to filter everything in that way it should work - and if this cannot be done via filtering with locations, sometimes you have to separate everything in organizations and then share some resources again
we also have customers, who separate windows and linux by using different organizations like areyus mentioned
In total I do not remember a scenario where nested organizations and locations were used, where they are needed. We have some customers using that but I think this is something where it isn’t exactly needed and could be achieved by adding just other organizations or locations.
Even those customers, who use the organization-separation usually only have 2 or 3 orgs. With locations it is usually less than 10. Most have 1 org and 1-3 locs.
We have customers, who share everything and those who like to separate everything, but this is currently not entirely possible without workaround (OS).
We probably also have scenarios, which I do not know about, since I am not the only one to setup, plan and maintain our customers setups - but I know many of them from the last 5+ years
This is possible by adding a user only to one location - so if you have an useraccount, which is only part of Boston, it shouldn’t see the hosts in Paris. Or do you misunderstand the question?
In the scenario I am currently thinking, the location is mainly used to filter which options are available during host deployment, so that the correct subnets, domains, smart_proxies are selected - or in most cases only a subset of the hostgroups are available as template for deployments.
I hope this can add something to the extensive post of the others. But maybe there are some details, which might different in my examples
Hey guys, a little background, we are running Foreman in a “retail” environment.
How many organizations do you use in your Foreman deployment?
Currently we have two organizations. One contains our “data center” systems, the other contains our retail systems, which includes store servers and point-of-sale cash registers.
Which resources are shared across several organizations?
To my knowledge, we don’t really share anything explicitly, however inside of both organizations, we have the CentOS 7 repositories which I believe is technically “shared”, rather than having duplicate packages.
Can you imagine not sharing resources or is that necessary for you?
Since we don’t really need to share much across the two organizations, this has never really come to mind!
Do you use nested organizations?
Nope
I know the above isn’t the most descriptive, but I hope it is helpful in some way. If there are any additional details you’d like to know, just ask!
