Where is the best place to leave feedback of RFI? We've ran into an issue
where I'd really like to have class parameters on "Config Groups" and was
wondering where I could make a feedback/suggestion.
If you just want to discuss ideas, then here is absolutely fine. If
you're certain of what you want already, then you can raise an issue on
our bug tracker [1].
Parameters in config groups could be very tricky to implement though,
so do share your thoughts on this 
Cheers
Greg
1: Foreman
···
On Tue, 2017-09-26 at 11:03 -0700, Mike Wilson wrote: > Where is the best place to leave feedback of RFI? We've ran into an > issue where I'd really like to have class parameters on "Config > Groups" and was wondering where I could make a feedback/suggestion.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).
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.
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).
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.
···
On Wednesday, September 27, 2017 at 4:09:48 AM UTC-5, Greg Sutcliffe wrote: > > On Tue, 2017-09-26 at 11:03 -0700, Mike Wilson wrote: > > Where is the best place to leave feedback of RFI? We've ran into an > > issue where I'd really like to have class parameters on "Config > > Groups" and was wondering where I could make a feedback/suggestion. > > If you just want to discuss ideas, then here is absolutely fine. If > you're certain of what you want already, then you can raise an issue on > our bug tracker [1]. > > Parameters in config groups could be very tricky to implement though, > so do share your thoughts on this :) > > Cheers > Greg > > 1: http://projects.theforeman.org/projects/foreman/issues/new > > >> 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
···
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.