Foreman howto

Support
1

Hello list,

I´m a little bit ashamed to write the dumbest question of the day…

I´ve got up my small puppet ecosystem running puppet 2.7.1 plus
foreman 0.3.1 with below ten nodes acting as a test environmet.

I see all of my test nodes within foreman including facts plus a few
imported modules from puppetforge (rsyslog, yum, …).

now I´d like to create a few groups like rhel5-base and so on to map
classes to my nodes - but unfortunately I can only select one host
group to a node?

how am I supposed to map more classes to certain nodes, for example I
´d like to group SAP-systems to prod/qs/test and then map different
user groups to these nodes.

thanks for your help

··· , Stefan
2

> Hello list,
>
> I´m a little bit ashamed to write the dumbest question of the day…
>
> I´ve got up my small puppet ecosystem running puppet 2.7.1 plus
> foreman 0.3.1 with below ten nodes acting as a test environmet.
>
> I see all of my test nodes within foreman including facts plus a few
> imported modules from puppetforge (rsyslog, yum, …).
>
> now I´d like to create a few groups like rhel5-base and so on to map
> classes to my nodes - but unfortunately I can only select one host
> group to a node?
>
> how am I supposed to map more classes to certain nodes, for example I
> ´d like to group SAP-systems to prod/qs/test and then map different
> user groups to these nodes.
>
> thanks for your help

Normally, a host group represent a host role or a template, where it
is up to you to define meaningful groups that fit your usage case.

additionally, each host has an environment setting, this should map to
puppet environments, where you might be using a different version of
your manifests.
So you could have something like SAP hostgroup and hosts that belongs
to the SAP group, these hosts can be in different environments.

Each hostgroup, usually contains a collection of other puppet modules
and parameters (variables/facts) and provisioning attributes, in the
recent version (currently only in git / daily snapshots), you also
get:

  • nesting of host groups (e.g. one group can inherit from another)
  • Virtual machine attributes (e.g. set default memory, network etc)
  • Domain / Subnet settings

Hope this answers your question,
Ohad

··· On Mon, Aug 8, 2011 at 6:01 PM, Stefan Wiederoder wrote:

,
Stefan

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en.

3

Hello Ohad,

thanks for your answer, my problem is that a node has many roles - one
is rhel5base, the other is sapprod and so on.

using environments seems to complicated for me, or at least for my
current puppet level.

I´m now running dashboard 1.1.1 and it seems to support this kind of
grouping/mapping.

unfortunately it lacks all other good stuff from foreman …

thanks

··· , Stefan
4

> Hello Ohad,
>
> thanks for your answer, my problem is that a node has many roles - one
> is rhel5base, the other is sapprod and so on.
>
> I'm not sure I fully understand, but imho something like rhel5base should
be auto included based on your OS facts rather then except foreman to do it
for you.
for example, lets say you have a hostgroup called base
that base class could auto include other classes based on the machine facts.

the only limitation we had - which was about one group cant inherit from
another group, is already resolved in the latest development version.

if you like to assign multiple roles into a host, and each roles
has parameters, which parameter wins?

> using environments seems to complicated for me, or at least for my
> current puppet level.
>
> I´m now running dashboard 1.1.1 and it seems to support this kind of
> grouping/mapping.
>
Its good that everyone can chose whats best for them :slight_smile:

Ohad

··· On Wed, Aug 10, 2011 at 5:55 PM, Stefan Wiederoder < stefanwiederoder@googlemail.com> wrote:
5

>
>> Hello Ohad,
>>
>> thanks for your answer, my problem is that a node has many roles - one
>> is rhel5base, the other is sapprod and so on.
>>
>> I'm not sure I fully understand, but imho something like rhel5base should
> be auto included based on your OS facts rather then except foreman to do it
> for you.
> for example, lets say you have a hostgroup called base
> that base class could auto include other classes based on the machine
> facts.
>
> the only limitation we had - which was about one group cant inherit from
> another group, is already resolved in the latest development version.
>
> if you like to assign multiple roles into a host, and each roles
> has parameters, which parameter wins?
>

I might jump in here, as it's something I used to do with Dashboard. Ideally
you should not have parameter conflicts - roles with similar attributes
should be subgroups, which we can already do in Foreman. However, I find
myself wanting to do something like:

MachineA: Build18,Europe
MachineB: Build20,America

So I have classes which are appropriate to a specific version of our
software, and classes appropriate to a given region. Trying to do that with
auto-includes is very messy. Subgroups work, but you end up with:

Build18/Europe
Build20/Europe
Build18/America
Build20/America

which means I duplicate a lot of information, and might make a mistake when
updating large numbers of groups.

I think multiple groups isn't necessarily wrong (as you say, it's use case
dependant). I can think of a couple of ways to solve the parameters problem.
The easiest way (although possibly confusing to the new user) is to do by
the order of the groups. So if I assign a group to Build18+Europe, then
Build18 wins, as it's earlier. Other options include adding a priority
weight to the parameters, or even showing conflicts on a host page and
allowing the user to specify.

I´m now running dashboard 1.1.1 and it seems to support this kind of
>> grouping/mapping.
>>
> Its good that everyone can chose whats best for them :slight_smile:
>

Indeed. This is only piece of functionality I miss from Dashboard -
Foreman is way superior in all other respects :smiley:

··· On 10 August 2011 20:47, Ohad Levy wrote: > On Wed, Aug 10, 2011 at 5:55 PM, Stefan Wiederoder < > stefanwiederoder@googlemail.com> wrote:
6

>
>>
>>> Hello Ohad,
>>>
>>> thanks for your answer, my problem is that a node has many roles - one
>>> is rhel5base, the other is sapprod and so on.
>>>
>>> I'm not sure I fully understand, but imho something like rhel5base should
>> be auto included based on your OS facts rather then except foreman to do it
>> for you.
>> for example, lets say you have a hostgroup called base
>> that base class could auto include other classes based on the machine
>> facts.
>>
>> the only limitation we had - which was about one group cant inherit from
>> another group, is already resolved in the latest development version.
>>
>> if you like to assign multiple roles into a host, and each roles
>> has parameters, which parameter wins?
>>
>
> I might jump in here, as it's something I used to do with Dashboard.
> Ideally you should not have parameter conflicts - roles with similar
> attributes should be subgroups, which we can already do in Foreman. However,
> I find myself wanting to do something like:
>
> MachineA: Build18,Europe
> MachineB: Build20,America
>
> So I have classes which are appropriate to a specific version of our
> software, and classes appropriate to a given region. Trying to do that with
> auto-includes is very messy. Subgroups work, but you end up with:
>
> Build18/Europe
> Build20/Europe
> Build18/America
> Build20/America
>

Why don't you simple pass the build version as parameter? which code
duplication do you get?

include "build${version}"

Ohad

··· On Thu, Aug 11, 2011 at 12:11 PM, Greg Sutcliffe wrote: > On 10 August 2011 20:47, Ohad Levy wrote: >> On Wed, Aug 10, 2011 at 5:55 PM, Stefan Wiederoder < >> stefanwiederoder@googlemail.com> wrote:

which means I duplicate a lot of information, and might make a mistake when
updating large numbers of groups.

I think multiple groups isn’t necessarily wrong (as you say, it’s use case
dependant). I can think of a couple of ways to solve the parameters problem.
The easiest way (although possibly confusing to the new user) is to do by
the order of the groups. So if I assign a group to Build18+Europe, then
Build18 wins, as it’s earlier. Other options include adding a priority
weight to the parameters, or even showing conflicts on a host page and
allowing the user to specify.

I´m now running dashboard 1.1.1 and it seems to support this kind of

grouping/mapping.

Its good that everyone can chose whats best for them :slight_smile:

Indeed. This is only piece of functionality I miss from Dashboard -
Foreman is way superior in all other respects :smiley:

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

7

Mmm, good point. I guess there's no technical reason I can't do that. It
feels logically wrong though. You're saying "For your first group of
classes, add them to a host group. For any groups of classes, you'll have to
go write a wrapper class." It feels like we're not being logically
consistent. For example, your way means means secondary groups can only be
created by people with access to the Puppet code. If I can create secondary
groups in Foreman, I can let regional managers decide what goes on their
boxes.

I'm willing to concede the point, though, since there is a different
solution, and more important bugs to squash :smiley:

Greg

··· On 11 August 2011 10:20, Ohad Levy wrote:

Why don’t you simple pass the build version as parameter? which code
duplication do you get?

include “build${version}”

Ohad