I have a question concerning the integration of Puppet and Foreman. I use
both products, Foreman as well as Puppet since several years and I think
both are great products. But I'm a little bit uncertain about the Foreman
integration with upcoming Puppet releases. What I saw so far in talks and
presentations is a development going in the direction puppetserver +
puppetdb + hiera (as site replacement and inside modules). If I read
between the lines it look like that ENC is not a preferred way of
controlling Puppet in the future. So it might be that the current Foreman
way of working, let Puppet push the reports into Foreman and controlling
Puppet via ENC is not the best way to integrate Puppet into Foreman in the
future.
Will there be an architectural change in upcoming Foreman releases to
switch to something like generating hiera data via foreman-proxy on the
Puppet master and getting host data out of puppetdb the same way instead of
reporting? I think something like this would also give more flexibility in
HA scenarios because Foreman does not necessarily to be HA as well. It also
gives the ability to use modules with inline hiera what is, if I'm correct,
not possible with ENC at the moment.
> Hi Foreman users,
> I have a question concerning the integration of Puppet and Foreman. I use
> both products, Foreman as well as Puppet since several years and I think
> both are great products. But I'm a little bit uncertain about the Foreman
> integration with upcoming Puppet releases. What I saw so far in talks and
> presentations is a development going in the direction puppetserver +
> puppetdb + hiera (as site replacement and inside modules). If I read
> between the lines it look like that ENC is not a preferred way of
> controlling Puppet in the future. So it might be that the current Foreman
> way of working, let Puppet push the reports into Foreman and controlling
> Puppet via ENC is not the best way to integrate Puppet into Foreman in the
> future.
I'm also interested in knowing more about this since I got the same
impression.
We're in the middle of migrating away from node definitions to something
more future proof and we're undecided about Hiera and Foreman.
I'd love to use Foreman for its inventory tracking and host deployment
capabilities, so I would be sad to drop it. So far, I considered three
options:
Foreman for host deployment, ENC and parameter assignment. No Hiera
Foreman for host deployment and ENC. Hiera to provide parameters. The
popular roles/profiles paradigm would be implemented via config groups
(profiles) and host groups (roles). Hiera provides the parameters to the
classes.
Foreman for host deployment only, does not act as an ENC. Hiera assigns
roles and profiles and passes the parameters to the classes
Let's see the situation:
Option 1 is good for centralization: in essence, Foreman would be the only
"data store" or "source of truth" about the infrastructure. I don't find
the smart parameters/smart classes feature flexible enough. I'm afraid it
might prove non-scalable in the long run, and not so clear to debug.
Option 2 is a good trade off, but there would be two different places where
to store information about nodes (roles/profiles in Foreman, params in
Hiera). This might confuse people.
Option 3 might be the best: Foreman would complement Hiera and the
infrastructure would be almost entirely versionable in case YAML or JSON
files are used as a Hiera backend.
Any opinion in regard from the Foreman/Puppet community?
It also gives the ability to use modules with inline hiera what is, if I'm
> correct, not possible with ENC at the moment.
I lost you here! What do you mean by "use modules with inline hiera"?
Regards
Nicola
···
On Thursday, February 19, 2015 at 3:45:57 PM UTC+1, thbe wrote:
I'm currently implementing option 2 in my infrastructure. We have 3 data
center locations with about 15-20 product teams, with an average of 3
products per team. Basically I am using the Roles/Profiles paradigm but my
config groups are my roles. I use my host groups to differentiate
product/technology and locations for obvious reasons and organizations to
separate product teams. So far it seems to be working pretty well. All of
my configuration data is in Hiera, I don't declare anything in Foreman
except for host group (which has a config group assigned to it).
Occasionally I need to create a global variable and assign it to a host
group to use in a profile but that is not very common. I am able to version
control everything and only have to update classes in Foreman when there is
a new role created. Other than that it is automated code deployments.
···
On Monday, June 29, 2015 at 10:32:20 AM UTC-4, Nicola V wrote:
>
> On Thursday, February 19, 2015 at 3:45:57 PM UTC+1, thbe wrote:
>
>> Hi Foreman users,
>> I have a question concerning the integration of Puppet and Foreman. I use
>> both products, Foreman as well as Puppet since several years and I think
>> both are great products. But I'm a little bit uncertain about the Foreman
>> integration with upcoming Puppet releases. What I saw so far in talks and
>> presentations is a development going in the direction puppetserver +
>> puppetdb + hiera (as site replacement and inside modules). If I read
>> between the lines it look like that ENC is not a preferred way of
>> controlling Puppet in the future. So it might be that the current Foreman
>> way of working, let Puppet push the reports into Foreman and controlling
>> Puppet via ENC is not the best way to integrate Puppet into Foreman in the
>> future.
>
>
> I'm also interested in knowing more about this since I got the same
> impression.
> We're in the middle of migrating away from node definitions to something
> more future proof and we're undecided about Hiera and Foreman.
> I'd love to use Foreman for its inventory tracking and host deployment
> capabilities, so I would be sad to drop it. So far, I considered three
> options:
>
> 1. Foreman for host deployment, ENC and parameter assignment. No Hiera
> 2. Foreman for host deployment and ENC. Hiera to provide parameters. The
> popular roles/profiles paradigm would be implemented via config groups
> (profiles) and host groups (roles). Hiera provides the parameters to the
> classes.
> 3. Foreman for host deployment only, does not act as an ENC. Hiera assigns
> roles and profiles and passes the parameters to the classes
>
> Let's see the situation:
> Option 1 is good for centralization: in essence, Foreman would be the only
> "data store" or "source of truth" about the infrastructure. I don't find
> the smart parameters/smart classes feature flexible enough. I'm afraid it
> might prove non-scalable in the long run, and not so clear to debug.
> Option 2 is a good trade off, but there would be two different places
> where to store information about nodes (roles/profiles in Foreman, params
> in Hiera). This might confuse people.
> Option 3 might be the best: Foreman would complement Hiera and the
> infrastructure would be almost entirely versionable in case YAML or JSON
> files are used as a Hiera backend.
>
> Any opinion in regard from the Foreman/Puppet community?
>
> It also gives the ability to use modules with inline hiera what is, if I'm
>> correct, not possible with ENC at the moment.
>
>
>
> I lost you here! What do you mean by "use modules with inline hiera"?
>
> Regards
> Nicola
>
Sitz der Gesellschaft: Hamburg, Amtsgericht Hamburg, HRB 74173
Vorstand: Christoph Friedlaender, Dr.-Ing. Thorsten Kuhlmann
Vorsitzender des Aufsichtsrats: Christian Gottsmann
Thanks Christopher, that sounds cool. I'm more inclined towards that
option, so far.
I wonder, on a side note: do you manage the networking config via puppet as
well, or do you just let Foreman set it up during deployment and eventually
fix it manually?
Regards,
Nicola
···
On Tuesday, June 30, 2015 at 3:04:46 PM UTC+2, Christopher Pisano wrote:
>
> I'm currently implementing option 2 in my infrastructure. We have 3 data
> center locations with about 15-20 product teams, with an average of 3
> products per team. Basically I am using the Roles/Profiles paradigm but my
> config groups are my roles. I use my host groups to differentiate
> product/technology and locations for obvious reasons and organizations to
> separate product teams. So far it seems to be working pretty well. All of
> my configuration data is in Hiera, I don't declare anything in Foreman
> except for host group (which has a config group assigned to it).
> Occasionally I need to create a global variable and assign it to a host
> group to use in a profile but that is not very common. I am able to version
> control everything and only have to update classes in Foreman when there is
> a new role created. Other than that it is automated code deployments.
>
We do something similar. We use the roles/profiles paradigm as well. For
us, a "role" is typically a hostgroup in Foreman. We don't currently use
config groups, but I should look into this. The host-groups traditionally
include "profile" classes which are outside of Foreman. The only downfall
to this is that we are unable to enforce a specific order of the profile
classes which are assigned to the hostgroup (role) in Foreman. When this
becomes an issue, we create a "role" class outside of Foreman, and just
assign this to the host-group.
Most of our data is kept in Hiera; we don't really use Smart vars. We use
Foreman to provision everything (physical and VMWare). We use "locations"
to segregate our datacenter locations. We use "organizations" to
differentiate between several internal business units/teams.
Overall, this allows a member of $organizationA to login to Foreman and
classify a node just by assigning the node to a host-group that he/she has
access to. I'm unsure on what the benefit of introducing config-groups
into this scenario would be?
···
On Tue, Jun 30, 2015 at 9:04 AM, Christopher Pisano wrote:
I’m currently implementing option 2 in my infrastructure. We have 3 data
center locations with about 15-20 product teams, with an average of 3
products per team. Basically I am using the Roles/Profiles paradigm but my
config groups are my roles. I use my host groups to differentiate
product/technology and locations for obvious reasons and organizations to
separate product teams. So far it seems to be working pretty well. All of
my configuration data is in Hiera, I don’t declare anything in Foreman
except for host group (which has a config group assigned to it).
Occasionally I need to create a global variable and assign it to a host
group to use in a profile but that is not very common. I am able to version
control everything and only have to update classes in Foreman when there is
a new role created. Other than that it is automated code deployments.
On Monday, June 29, 2015 at 10:32:20 AM UTC-4, Nicola V wrote:
On Thursday, February 19, 2015 at 3:45:57 PM UTC+1, thbe wrote:
Hi Foreman users,
I have a question concerning the integration of Puppet and Foreman. I
use both products, Foreman as well as Puppet since several years and I
think both are great products. But I’m a little bit uncertain about the
Foreman integration with upcoming Puppet releases. What I saw so far in
talks and presentations is a development going in the direction
puppetserver + puppetdb + hiera (as site replacement and inside modules).
If I read between the lines it look like that ENC is not a preferred way of
controlling Puppet in the future. So it might be that the current Foreman
way of working, let Puppet push the reports into Foreman and controlling
Puppet via ENC is not the best way to integrate Puppet into Foreman in the
future.
I’m also interested in knowing more about this since I got the same
impression.
We’re in the middle of migrating away from node definitions to something
more future proof and we’re undecided about Hiera and Foreman.
I’d love to use Foreman for its inventory tracking and host deployment
capabilities, so I would be sad to drop it. So far, I considered three
options:
Foreman for host deployment, ENC and parameter assignment. No Hiera
Foreman for host deployment and ENC. Hiera to provide parameters. The
popular roles/profiles paradigm would be implemented via config groups
(profiles) and host groups (roles). Hiera provides the parameters to the
classes.
Foreman for host deployment only, does not act as an ENC. Hiera
assigns roles and profiles and passes the parameters to the classes
Let’s see the situation:
Option 1 is good for centralization: in essence, Foreman would be the
only “data store” or “source of truth” about the infrastructure. I don’t
find the smart parameters/smart classes feature flexible enough. I’m afraid
it might prove non-scalable in the long run, and not so clear to debug.
Option 2 is a good trade off, but there would be two different places
where to store information about nodes (roles/profiles in Foreman, params
in Hiera). This might confuse people.
Option 3 might be the best: Foreman would complement Hiera and the
infrastructure would be almost entirely versionable in case YAML or JSON
files are used as a Hiera backend.
Any opinion in regard from the Foreman/Puppet community?
It also gives the ability to use modules with inline hiera what is, if
I’m correct, not possible with ENC at the moment.
I lost you here! What do you mean by “use modules with inline hiera”?
My environment is strictly DHCP. I let the Smart-Proxy handle creating the
reservations and the DNS entries. Puppet controls the DNS configs on the
deployed hosts though. . . not sure if that answers your question.
···
On Tue, Jun 30, 2015 at 9:22 AM, Nicola V wrote:
On Tuesday, June 30, 2015 at 3:04:46 PM UTC+2, Christopher Pisano wrote:
I’m currently implementing option 2 in my infrastructure. We have 3 data
center locations with about 15-20 product teams, with an average of 3
products per team. Basically I am using the Roles/Profiles paradigm but my
config groups are my roles. I use my host groups to differentiate
product/technology and locations for obvious reasons and organizations to
separate product teams. So far it seems to be working pretty well. All of
my configuration data is in Hiera, I don’t declare anything in Foreman
except for host group (which has a config group assigned to it).
Occasionally I need to create a global variable and assign it to a host
group to use in a profile but that is not very common. I am able to version
control everything and only have to update classes in Foreman when there is
a new role created. Other than that it is automated code deployments.
Thanks Christopher, that sounds cool. I’m more inclined towards that
option, so far.
I wonder, on a side note: do you manage the networking config via puppet
as well, or do you just let Foreman set it up during deployment and
eventually fix it manually?
The benefit of config groups for me is that I can assign a role to a config
group, give that config group a user friendly name and assign it to a host
group. That way when the user goes to look at the host group or what is
applied to their servers they don't have to decipher roles::foo. They see
something friendly like $product_app or $product_web. Technically speaking
config groups don't give me any more functionality than just applying a
roles class.
···
On Tue, Jun 30, 2015 at 9:34 AM, Josh Baird wrote:
We do something similar. We use the roles/profiles paradigm as well. For
us, a “role” is typically a hostgroup in Foreman. We don’t currently use
config groups, but I should look into this. The host-groups traditionally
include “profile” classes which are outside of Foreman. The only downfall
to this is that we are unable to enforce a specific order of the profile
classes which are assigned to the hostgroup (role) in Foreman. When this
becomes an issue, we create a “role” class outside of Foreman, and just
assign this to the host-group.
Most of our data is kept in Hiera; we don’t really use Smart vars. We use
Foreman to provision everything (physical and VMWare). We use "locations"
to segregate our datacenter locations. We use “organizations” to
differentiate between several internal business units/teams.
Overall, this allows a member of $organizationA to login to Foreman and
classify a node just by assigning the node to a host-group that he/she has
access to. I’m unsure on what the benefit of introducing config-groups
into this scenario would be?
On Tue, Jun 30, 2015 at 9:04 AM, Christopher Pisano cpisano86@gmail.com > wrote:
I’m currently implementing option 2 in my infrastructure. We have 3 data
center locations with about 15-20 product teams, with an average of 3
products per team. Basically I am using the Roles/Profiles paradigm but my
config groups are my roles. I use my host groups to differentiate
product/technology and locations for obvious reasons and organizations to
separate product teams. So far it seems to be working pretty well. All of
my configuration data is in Hiera, I don’t declare anything in Foreman
except for host group (which has a config group assigned to it).
Occasionally I need to create a global variable and assign it to a host
group to use in a profile but that is not very common. I am able to version
control everything and only have to update classes in Foreman when there is
a new role created. Other than that it is automated code deployments.
On Monday, June 29, 2015 at 10:32:20 AM UTC-4, Nicola V wrote:
On Thursday, February 19, 2015 at 3:45:57 PM UTC+1, thbe wrote:
Hi Foreman users,
I have a question concerning the integration of Puppet and Foreman. I
use both products, Foreman as well as Puppet since several years and I
think both are great products. But I’m a little bit uncertain about the
Foreman integration with upcoming Puppet releases. What I saw so far in
talks and presentations is a development going in the direction
puppetserver + puppetdb + hiera (as site replacement and inside modules).
If I read between the lines it look like that ENC is not a preferred way of
controlling Puppet in the future. So it might be that the current Foreman
way of working, let Puppet push the reports into Foreman and controlling
Puppet via ENC is not the best way to integrate Puppet into Foreman in the
future.
I’m also interested in knowing more about this since I got the same
impression.
We’re in the middle of migrating away from node definitions to something
more future proof and we’re undecided about Hiera and Foreman.
I’d love to use Foreman for its inventory tracking and host deployment
capabilities, so I would be sad to drop it. So far, I considered three
options:
Foreman for host deployment, ENC and parameter assignment. No Hiera
Foreman for host deployment and ENC. Hiera to provide parameters. The
popular roles/profiles paradigm would be implemented via config groups
(profiles) and host groups (roles). Hiera provides the parameters to the
classes.
Foreman for host deployment only, does not act as an ENC. Hiera
assigns roles and profiles and passes the parameters to the classes
Let’s see the situation:
Option 1 is good for centralization: in essence, Foreman would be the
only “data store” or “source of truth” about the infrastructure. I don’t
find the smart parameters/smart classes feature flexible enough. I’m afraid
it might prove non-scalable in the long run, and not so clear to debug.
Option 2 is a good trade off, but there would be two different places
where to store information about nodes (roles/profiles in Foreman, params
in Hiera). This might confuse people.
Option 3 might be the best: Foreman would complement Hiera and the
infrastructure would be almost entirely versionable in case YAML or JSON
files are used as a Hiera backend.
Any opinion in regard from the Foreman/Puppet community?
It also gives the ability to use modules with inline hiera what is, if
I’m correct, not possible with ENC at the moment.
I lost you here! What do you mean by “use modules with inline hiera”?
