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?
> 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?
> In short, we need Config Groups to have parameter options so we can
> have settings for those specific Config Groups. The plan originally
> was to have Config Groups be setup so that each group was a service.
> So, things like Apache, NTP, Mail/etc and each of those requires
> specific options for those groups while those not in those groups
> would need other options (normal machine wouldn't need to special
> mail server configs of say our primary mail spool).
So the elephant in the room is Config Group conflicts. We allow the
same classes to exist in multiple groups, so consdier a Host with these
two groups assigned:
group1:
classes:
dns:
country: usa
group2:
classes:
dns:
country: uk
In Puppet this would throw an error (you're basically doing two 'class
{ 'dns': ... }' calls with different params), but in Foreman we have no
way to handle it. Params can be constructed from facts, so we can't
parse them ahead of time to check for conflicts and warn the user. We
have no way to set some kind of 'priority' on Config Groups to
determine who "wins" a conflict, and even that's only good if you don't
want merge-tree behaviour, etc.
It's such a messy problem, so we decided it would be safer to do what
Puppet does - you can "include ::dns" as many times as you like in
Puppet, so long as you don't specify params :)
> 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.
HTH
Greg
--
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.
