We’ve been an older version of Foreman for a while, but only recently started using Foreman 1.20. Upon upgrading to 1.21 I noticed this Headline Feature:
The Foreman Manual doesn’t seem to have an explanation on how to use Locations & Organizations properly, or what they are really. Can someone point me in the right direction?
Our Foreman instance is currently used by a team of 6 people in one large datacenter. We might use multiple clouds for some projects in the future, and currently, we really only have one ‘Location’ at the moment. Is there an easy way to ensure that all of my resources are assigned to a default organization & location from the start?
So I think organizations are mostly useful for bigger environments where subscriptions or hosts have to be separated like in our own environment where we have a separate organization for every big customer with access to Foreman.
Locations are more helpful also in smaller environments to help you organize things, so having smart proxies, subnets, domains assigned to the location will prevent someone choosing bad combinations. We use this in our own environment for separating the datacenters and I implemented it in a similar way for multiple customers.
As Dirk said, these are features for large companies. We have users managing 100,000+ hosts across the globe. Just use a single Org and Loc, we understand this might be extra work and care for you, but it makes life of a developer much easier to have them enabled.
Unfortunately no, make sure the organization is always selected in the top picker, location as well. All new resources “should” be assigned, if its not report a bug. Unfortunately taxonomy errors are weird, e.g. a host reports nil template but the real cause is that the template was not assigned to the host’s org. These are hard to spot and we can’t do much better due to design of how we implemented all of this.
For users who are assigned to a single org or loc, they shouldn’t even see the top bar picker AFAIK. Also user is automatically switched to that context. And therefore whenever you create or edit a resource, the default organization and location should be prefilled in the form.
That’s the theory. In practice you can have resources that are not assigned to an org or a location so they appear to be missing. It’s why we have this workaround in our pipeline:
That sounds reasonable. Pretty sure I’ve had some new resources which were not assigned to my Org & Location, and I had to reassign them manually. Unfortunately, I didn’t notice until there was a problem-- the configuration for a new host didn’t list the correct Installation Media, for example. If this keeps happening, I’ll try to file a ticket.
Aha, this is likely the issue. I had granted us all the ‘Administrator’ role, which seems to be some sort of super-role, which shows the top bar picker.
Since we aren’t actually using Organizations or Locations, what’s the best role for my team of 6? I’m unclear if I should grant everyone the ‘Manager’ role or the ‘Organization Administrator’ role. We may have multiple Locations in the future.
It depends on how much you trust your users or what you need to restrict. You’ll encounter the least amount of problems with having everybody administrator. This is not a role but rather checkbox on user / user group level. Foreman skips pernission check for such users, so pages even load a bit faster. Manager role aims to be the same, but without skipping permission checks. Non admin users can not switch to “Any organization” and in general can’t see resources from orgs they are nit assigned to. The same applies for locations.
Locations are amazing for making efficient use of the ENC. I love configuring location specific variable(s) and using them in my puppet code stuff like proxy servers, sssd config params, locak yumserver locations, or DNS servers (we use 3 per location, so using the subnet value isn’t enough).
Organizations are good for multi-tenency - keeping group X from seeing Y stuff, or only having RO access to Y stuff… etc.
I really “wish” I could configure parameters on environment(s) as well. For now - I settle for using ERB snippet(s) in global variables with case statements for environment(s) - the only downside here is REST calls show the ERB and not the evaluated value(s) - which makes sense since it has nothing to evaluate “against” but confuses people sometimes…
