As you've already discovered, Foreman's pretty flexible, so what follows is
simply my take - there are plenty of ways you could solve this.
The ganglia parameter is pretty easy - since it's specific to the role of
the machine, set the parameter at the hostgroup level. You could use a
global parameter, or (from Foreman 1.2 onwards) we also support overriding
class parameters at the host group level.
For the dns parameter, my first thought is to use the Locations support in
Foreman, but sadly we don't support class parameter matchers against
Locations/Organisations yet.
Assuming the two datacentres have a different subdomain (which your regexes
suggest is true) then you could set Domain Parameters and assign the hosts
into the correct domain. These are global again ($::dns_domain) in puppet,
so you may need a wrapper class if they're meant to be used as part of a
class definition.
Hope that helps,
Greg
···
On 28 May 2013 19:40, wrote:
Hi all,
We’re attempting to use Foreman in a large-scale environment and have a
question. We already use puppet for hundreds of hosts and are trying to
incorporate Foreman. As you can see there are two variables at play here:
$ganglia_group and $dns_server. $dns_server is specific to the datacenter
(i.e. dc1 or dc2), while $ganglia_group is specific to what the machine is
(i.e. database or webserver.) How can we use Foreman’s parameters and smart
parameters to emulate this same behavior?
>
>> Hi all,
>>
>> We're attempting to use Foreman in a large-scale environment and have a
>> question. We already use puppet for hundreds of hosts and are trying to
>> incorporate Foreman. As you can see there are two variables at play here:
>> $ganglia_group and $dns_server. $dns_server is specific to the datacenter
>> (i.e. dc1 or dc2), while $ganglia_group is specific to what the machine is
>> (i.e. database or webserver.) How can we use Foreman's parameters and smart
>> parameters to emulate this same behavior?
>>
>
> As you've already discovered, Foreman's pretty flexible, so what follows
> is simply my take - there are plenty of ways you could solve this.
>
> The ganglia parameter is pretty easy - since it's specific to the role of
> the machine, set the parameter at the hostgroup level. You could use a
> global parameter, or (from Foreman 1.2 onwards) we also support overriding
> class parameters at the host group level.
>
> We support overrinding it since 1.1, but that would be via the matcher
screen (editing a class and adding a matcher for hostgroup) vs. the simple
ui like in the host edit form.
> For the dns parameter, my first thought is to use the Locations support in
> Foreman, but sadly we don't support class parameter matchers against
> Locations/Organisations yet.
>
Why not? afaik if you add it to the order list, it should work.
>
> Assuming the two datacentres have a different subdomain (which your
> regexes suggest is true) then you could set Domain Parameters and assign
> the hosts into the correct domain. These are global again ($::dns_domain)
> in puppet, so you may need a wrapper class if they're meant to be used as
> part of a class definition.
>
If the host is already related to a domain in foreman, I wonder why you
would need this in the first place?
Ohad
···
On Tue, May 28, 2013 at 10:05 PM, Greg Sutcliffe wrote:
> On 28 May 2013 19:40, wrote:
Hope that helps,
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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
> The ganglia parameter is pretty easy - since it's specific to the role of
> the machine, set the parameter at the hostgroup level. You could use a
> global parameter, or (from Foreman 1.2 onwards) we also support overriding
> class parameters at the host group level.
>
>>
>> We support overrinding it since 1.1, but that would be via the matcher
> screen (editing a class and adding a matcher for hostgroup) vs. the simple
> ui like in the host edit form.
>
Yep, but the OP is staing that he's trying to avoid large-scale duplication
of matchers, so I thought it important to emphasise the simple-ui side of
the work in this case.
>
>
>> For the dns parameter, my first thought is to use the Locations support
>> in Foreman, but sadly we don't support class parameter matchers against
>> Locations/Organisations yet.
>>
> Why not? afaik if you add it to the order list, it should work.
>
I was remembering Feature #2334: location matcher doesn't match on smart parameters - Foreman but is seems
Joseph's been busy ;). If it works, then Locations is a natural fit here.
>
>
Assuming the two datacentres have a different subdomain (which your
>> regexes suggest is true) then you could set Domain Parameters and assign
>> the hosts into the correct domain. These are global again ($::dns_domain)
>> in puppet, so you may need a wrapper class if they're meant to be used as
>> part of a class definition.
>>
> If the host is already related to a domain in foreman, I wonder why you
> would need this in the first place?
>
I'm just covering the bases - if the OP is, for example, using mostly
unmanaged hosts then re-stating the ability to add domains and that they
have a place in the parameter hierarchy is useful.
Greg
···
On 28 May 2013 20:34, Ohad Levy wrote:
Smart variables can override default value based on a location matcher if "location" is added to the order list. It works for me. I hope we can find the root cause of issue #2334, but in general it should be no problem to match on location or organization.
Joseph
···
----- Original Message -----
From: "Greg Sutcliffe"
To: "Foreman ."
Sent: Tuesday, May 28, 2013 10:39:43 PM
Subject: Re: [foreman-users] Foreman Parameter Handling
On 28 May 2013 20:34, Ohad Levy ohadlevy@gmail.com wrote:
The ganglia parameter is pretty easy - since it’s specific to the role of
the machine, set the parameter at the hostgroup level. You could use a
global parameter, or (from Foreman 1.2 onwards) we also support overriding
class parameters at the host group level.
We support overrinding it since 1.1, but that would be via the matcher
screen (editing a class and adding a matcher for hostgroup) vs. the simple
ui like in the host edit form.
Yep, but the OP is staing that he’s trying to avoid large-scale duplication
of matchers, so I thought it important to emphasise the simple-ui side of
the work in this case.
For the dns parameter, my first thought is to use the Locations support
in Foreman, but sadly we don’t support class parameter matchers against
Locations/Organisations yet.
Why not? afaik if you add it to the order list, it should work.
I was remembering Feature #2334: location matcher doesn’t match on smart parameters - Foreman but is seems
Joseph’s been busy ;). If it works, then Locations is a natural fit here.
Assuming the two datacentres have a different subdomain (which your
regexes suggest is true) then you could set Domain Parameters and assign
the hosts into the correct domain. These are global again ($::dns_domain)
in puppet, so you may need a wrapper class if they’re meant to be used as
part of a class definition.
If the host is already related to a domain in foreman, I wonder why you
would need this in the first place?
I’m just covering the bases - if the OP is, for example, using mostly
unmanaged hosts then re-stating the ability to add domains and that they
have a place in the parameter hierarchy is useful.
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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
