On Thursday, October 5, 2017 at 5:52:35 AM UTC-5, Greg Sutcliffe wrote: > > On Mon, 2017-10-02 at 08:51 -0700, Mike Wilson wrote: > > The reason I was thinking it would solve a problem is ... currently > > we use "HostGroups" as a location based setting. Pop has a specific > > hostgroup so that when the user goes to build a host his settings are > > set for "defaults" for that locale (such as puppet master, puppet CA, > > subnets/etc). Because of that we have a need of assigning puppet > > classes to a host group with specific parameters. So, applying a > > Config Group "dns-servers" would make sure all the classes for dns- > > servers puppet are applied to the server. In this case we'd need to > > be able to apply certain parameters to the "group" for those settings > > (such as specific firewall settings, dns settings/etc). > > This is fine, and plenty of people do this. Using Smart Class > Parameters that match on Hostgroup should give you the flexibility you > need - is there some other reason you'd like to move away from using > Hostgroups for this? >
Mostly because right now location based hostgroups has worked out much better. Using the location/org features doesn't really do the same. Mainly specific to the inherit settings in a hostgroup. Now you can limit those by location or org but if the user has access to multiple locations/orgs and doesn't "set" their current scope to those loc/orgs all the options for them will be listed. It's just less prone to error (IMO) with the "soft locked" inherit options of host groups. > > > Now, if we switch to using host groups as a Host-Service we can get > > around this (and we're moving that way now) but because of that we > > really won't use Config Groups at all. They really don't buy us a lot > > unless we can set specific parameters for them. > > Agreed, you won't gain much, but as above, I'm not sure that you need > them anyway? > If we use host groups as a service (and not pop location) with associated parameters using smart class parameters for host groups seems redundant (assign those on the host group itself)? Is there a reason to just have the hostgroup as service in name only and then manage it in the class with smart class on hostgroup names? > > Maybe there is a better way to do this and I'm just not seeing it. > > We're still REALLY new at provisioning with Foreman. > > It does sound like Hostgroups could fill your needs, unless I'm missing > something. Another option is to edit the Foreman settings file and > enable Locations - but this adds a lot of complexity to the UI as > nearly everything (Proxies, Domains, Subnets, Hosts, etc) get scoped to > one-or-more Locations then. Still, it may be useful to you, as it's > another thing params can match on. > We have been trying to work with location/org based options enabled but I couldn't see a good way to have that manage our "service" based hosts that worked out well. I'll take another look at it and see what I can figure out. -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
