Foreman Git branches and Puppet Environments

I'm just starting out with git, puppet and foreman, and I'm interested in
using puppet environments for separating puppet modules I'm developing or
making changes to from ready to use modules.

I created a ntp module using parameterized classes, then created two git
branches dev and prod. I added two extra parameters to the development ntp
module branch. Setup the puppet.conf with the environment paths and
imported the environments into foreman. When I go to edit the ntp class
parameter, I see all parameters from both environments. When I filter only
the production environment, I still see the two extra parameters from the
development module. Then I deleted the development environment from
Foreman, remove the contents from the filesystem. Then viewed the
parameters for the class and still see the two extra parameters that's only
available in the development branch.

What I expected was to keep my development and production
modules completely separate using foreman environments. When I want to test
a module, just change the host environment and issue a puppet run from
foreman.

Is this not the expected behavior?

I'm really happy you bring this up :slight_smile: as we spent quite some time trying to
figure out how to best address this.

Foreman solution around parameters, is trying to solve two problems:

  1. integrate with puppet ENC (e.g. the ability to tell puppet which
    class/params to use)
  2. define the value of parameter to use

Since we already had the concept of Smart variables, where a value can
be automatically selected based of the host properties (e.g. for this
domain, use this ntp value), we integrated the two.

now, we were facing the question of:
should smartvars (in their param classes nature) should be isolated per
environment or not

the benefits was

  • complete separation between environments
    the disadvantage however was:
  • you can't reuse values
    for example, if you have ntp server parameter, you would not be able to
    share value from prod and dev, even if they are the same.

so instead, we decided we'll keep each parameter across environments,
however, we'll define a few things
a. keep a record of which env this param is relevant for
b. allow you to override the value per env, in the same way you would
override it per domain.

This gives you from one hand flexibility, and the ability to see all
possible values of a given parameter across all hosts, domains, env etc in
one place.
however, if you change the default value, you would change it too all
systems.

When you say you can see the parameter (when using the filter), isn't it
greyed out?

Regarding parameters that don't get deleted, well, since its data, we did
not feel comfortable that the import process can delete parameters and
their values, allowing you to delete both the classes and their params
manually if you want.

what do you think?

Ohad

··· On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote:

I’m just starting out with git, puppet and foreman, and I’m interested in
using puppet environments for separating puppet modules I’m developing or
making changes to from ready to use modules.

I created a ntp module using parameterized classes, then created two git
branches dev and prod. I added two extra parameters to the development ntp
module branch. Setup the puppet.conf with the environment paths and
imported the environments into foreman. When I go to edit the ntp class
parameter, I see all parameters from both environments. When I filter only
the production environment, I still see the two extra parameters from the
development module. Then I deleted the development environment from
Foreman, remove the contents from the filesystem. Then viewed the
parameters for the class and still see the two extra parameters that’s only
available in the development branch.

What I expected was to keep my development and production
modules completely separate using foreman environments. When I want to test
a module, just change the host environment and issue a puppet run from
foreman.

Is this not the expected behavior?

>
>
>
>
>
>> I'm just starting out with git, puppet and foreman, and I'm interested in
>> using puppet environments for separating puppet modules I'm developing or
>> making changes to from ready to use modules.
>>
>> I created a ntp module using parameterized classes, then created two git
>> branches dev and prod. I added two extra parameters to the development ntp
>> module branch. Setup the puppet.conf with the environment paths and
>> imported the environments into foreman. When I go to edit the ntp class
>> parameter, I see all parameters from both environments. When I filter only
>> the production environment, I still see the two extra parameters from the
>> development module. Then I deleted the development environment from
>> Foreman, remove the contents from the filesystem. Then viewed the
>> parameters for the class and still see the two extra parameters that's only
>> available in the development branch.
>>
>> What I expected was to keep my development and production
>> modules completely separate using foreman environments. When I want to test
>> a module, just change the host environment and issue a puppet run from
>> foreman.
>>
>> Is this not the expected behavior?
>>
>
> I'm really happy you bring this up :slight_smile: as we spent quite some time trying
> to figure out how to best address this.
>
> Foreman solution around parameters, is trying to solve two problems:
> 1. integrate with puppet ENC (e.g. the ability to tell puppet which
> class/params to use)
> 2. define the value of parameter to use
>
> Since we already had the concept of Smart variables, where a value can
> be automatically selected based of the host properties (e.g. for this
> domain, use this ntp value), we integrated the two.
>
> now, we were facing the question of:
> should smartvars (in their param classes nature) should be isolated per
> environment or not
>
> the benefits was
> - complete separation between environments
> the disadvantage however was:
> - you can't reuse values
> for example, if you have ntp server parameter, you would not be able to
> share value from prod and dev, even if they are the same.
>
> so instead, we decided we'll keep each parameter across environments,
> however, we'll define a few things
> a. keep a record of which env this param is relevant for
> b. allow you to override the value per env, in the same way you would
> override it per domain.
>
> This gives you from one hand flexibility, and the ability to see all
> possible values of a given parameter across all hosts, domains, env etc in
> one place.
> however, if you change the default value, you would change it too all
> systems.
>
> When you say you can see the parameter (when using the filter), isn't it
> greyed out?
>

I think is was grayed out.

>
>

>

> Regarding parameters that don't get deleted, well, since its data, we did
> not feel comfortable that the import process can delete parameters and
> their values, allowing you to delete both the classes and their params
> manually if you want.
>
> what do you think?
>
> Ohad
>
>
When you remove a class you should have an option to remove any values
associated with its params. This allows for my use case, where I am only
using environments to separate puppet code I developing from puppet code
that can be applied to systems. This way an environment gets cleaned up
when a class is removed.

Base on your reasons for reasons for keeping each parameter across
environments, I can imagine use cases where this works perfectly. An
explanation of the environment I'm trying to fit foreman with puppet into
is necessary to help understand why I think it should be separated.

First we have locations: east, west; these are mapped perfectly to (Foreman
RC) Locations which are mapped to a hostgroup.

Then we have various targets, RHEV, Vsphere, Physical, Openstack, which
maps perfectly to the "Deploy on" option when you build a new host.

Take for example the Vsphere target, we have many clusters, datastores,
networks which maps perfectly to foreman's "Virtual Machine", "Operating
System", "Network". And Foreman allows for setting what these defaults
should be using a hostgroups.

Finally where a host end up running is determined by the following:

  • Locations - East, West
  • Environments - Dev, Test, Prod
  • Teirs - (Dev: a, b c…) (Test: a, b, c…) and same for Prod
  • Role - Jboss, Oracle, etc…
  • Network - is determined by role, tier, environment

With this in mind hostgroups seems like the best way to ensure a host ends
up running where it should. I could not figure out how to map things into
Puppet concept of environments, and then eventually Foreman. This is how I
arrive at the decision to use Puppet/Foreman environments only for
separating my puppet code. And for this use case, keeping classes separate
per environment makes sense.

Here's the next issue, Foreman ties classes to environments and you can
only override a param in two places "Host" or "Pupept Class" -> "Smart
Class Parameter". From Smart parameter, you can apply a class to multiple
hostgroups which pretty much set some default params for all hostgroups
selected. Now you can make exceptions for select hostgroups or other paths
using the "Override Value For Specific Hosts". To me, this is fine for
users who mostly/only use Foreman as an ENC, but flawed for those who use
Foreman for complete host lifecycle.
I should be able to override puppet class param at the hostgroup level.
This way, I can setup my puppet class to accept a tier or role or even
environment as a parameter. Our view is; for normal Foreman parameters,
global and the ones you can create at the hostgroup level. These are only
relevant to things, like snippets, and provision templates. And these are
usually only applicable when you kickstart/pxe boot a host. If you are
building a host from an image, then most of the things you want to do with
it (place in the correct cluster, network, domain) Foreman already does
well. Once its online, majority if not all the things I want to do can be
done using puppet. This makes setting puppet class param at the hostgroup
level ideal for us.

··· On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: > On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron <swy...@gmail.com > > wrote:

>
>
>
>>
>>
>>
>>
>>> I'm just starting out with git, puppet and foreman, and I'm interested
>>> in using puppet environments for separating puppet modules I'm developing
>>> or making changes to from ready to use modules.
>>>
>>> I created a ntp module using parameterized classes, then created two git
>>> branches dev and prod. I added two extra parameters to the development ntp
>>> module branch. Setup the puppet.conf with the environment paths and
>>> imported the environments into foreman. When I go to edit the ntp class
>>> parameter, I see all parameters from both environments. When I filter only
>>> the production environment, I still see the two extra parameters from the
>>> development module. Then I deleted the development environment from
>>> Foreman, remove the contents from the filesystem. Then viewed the
>>> parameters for the class and still see the two extra parameters that's only
>>> available in the development branch.
>>>
>>> What I expected was to keep my development and production
>>> modules completely separate using foreman environments. When I want to test
>>> a module, just change the host environment and issue a puppet run from
>>> foreman.
>>>
>>> Is this not the expected behavior?
>>>
>>
>> I'm really happy you bring this up :slight_smile: as we spent quite some time trying
>> to figure out how to best address this.
>>
>> Foreman solution around parameters, is trying to solve two problems:
>> 1. integrate with puppet ENC (e.g. the ability to tell puppet which
>> class/params to use)
>> 2. define the value of parameter to use
>>
>> Since we already had the concept of Smart variables, where a value can
>> be automatically selected based of the host properties (e.g. for this
>> domain, use this ntp value), we integrated the two.
>>
>> now, we were facing the question of:
>> should smartvars (in their param classes nature) should be isolated per
>> environment or not
>>
>> the benefits was
>> - complete separation between environments
>> the disadvantage however was:
>> - you can't reuse values
>> for example, if you have ntp server parameter, you would not be able to
>> share value from prod and dev, even if they are the same.
>>
>> so instead, we decided we'll keep each parameter across environments,
>> however, we'll define a few things
>> a. keep a record of which env this param is relevant for
>> b. allow you to override the value per env, in the same way you would
>> override it per domain.
>>
>> This gives you from one hand flexibility, and the ability to see all
>> possible values of a given parameter across all hosts, domains, env etc in
>> one place.
>> however, if you change the default value, you would change it too all
>> systems.
>>
>> When you say you can see the parameter (when using the filter), isn't it
>> greyed out?
>>
>
> I think is was grayed out.
>
>
>>
>>
>
>>
>
>> Regarding parameters that don't get deleted, well, since its data, we did
>> not feel comfortable that the import process can delete parameters and
>> their values, allowing you to delete both the classes and their params
>> manually if you want.
>>
>> what do you think?
>>
>> Ohad
>>
>>
> When you remove a class you should have an option to remove any values
> associated with its params. This allows for my use case, where I am only
> using environments to separate puppet code I developing from puppet code
> that can be applied to systems. This way an environment gets cleaned up
> when a class is removed.
>
> Base on your reasons for reasons for keeping each parameter across
> environments, I can imagine use cases where this works perfectly. An
> explanation of the environment I'm trying to fit foreman with puppet into
> is necessary to help understand why I think it should be separated.
>
> ****
>
> First we have locations: east, west; these are mapped perfectly to
> (Foreman RC) Locations which are mapped to a hostgroup.
>
> ****
>
> Then we have various targets, RHEV, Vsphere, Physical, Openstack, which
> maps perfectly to the "Deploy on" option when you build a new host.
>
> ****
>
> Take for example the Vsphere target, we have many clusters, datastores,
> networks which maps perfectly to foreman's "Virtual Machine", "Operating
> System", "Network". And Foreman allows for setting what these defaults
> should be using a hostgroups.
>
> ****
>
> Finally where a host end up running is determined by the following:
>
> * Locations - East, West
> * Environments - Dev, Test, Prod
> * Teirs - (Dev: a, b c…) (Test: a, b, c…) and same for Prod
> * Role - Jboss, Oracle, etc…
> * Network - is determined by role, tier, environment
>
> With this in mind hostgroups seems like the best way to ensure a host ends
> up running where it should. I could not figure out how to map things into
> Puppet concept of environments, and then eventually Foreman. This is how I
> arrive at the decision to use Puppet/Foreman environments only for
> separating my puppet code. And for this use case, keeping classes separate
> per environment makes sense.
>
> Here's the next issue, Foreman ties classes to environments and you can
> only override a param in two places "Host" or "Pupept Class" -> "Smart
> Class Parameter". From Smart parameter, you can apply a class to multiple
> hostgroups which pretty much set some default params for all hostgroups
> selected. Now you can make exceptions for select hostgroups or other paths
> using the "Override Value For Specific Hosts". To me, this is fine for
> users who mostly/only use Foreman as an ENC, but flawed for those who use
> Foreman for complete host lifecycle.
> I should be able to override puppet class param at the hostgroup level.
> This way, I can setup my puppet class to accept a tier or role or even
> environment as a parameter. Our view is; for normal Foreman parameters,
> global and the ones you can create at the hostgroup level. These are only
> relevant to things, like snippets, and provision templates. And these are
> usually only applicable when you kickstart/pxe boot a host. If you are
> building a host from an image, then most of the things you want to do with
> it (place in the correct cluster, network, domain) Foreman already does
> well. Once its online, majority if not all the things I want to do can be
> done using puppet. This makes setting puppet class param at the hostgroup
> level ideal for us.
>
> I think there are two issues here:

  1. we should have override class params in the hostgroup page too, afair,
    there is an open issue for that.
  2. you want to have per compute resource defaults, such as Hostgroup XYZ
    running on vsphere in location ZZZ should get this hw profile as default?

Ohad

··· On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron wrote: > On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: >> On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote:


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/eeK6MySE2ysJ.

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.

>
>
>
>
>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>> I'm just starting out with git, puppet and foreman, and I'm interested
>>>> in using puppet environments for separating puppet modules I'm developing
>>>> or making changes to from ready to use modules.
>>>>
>>>> I created a ntp module using parameterized classes, then created two
>>>> git branches dev and prod. I added two extra parameters to the development
>>>> ntp module branch. Setup the puppet.conf with the environment paths and
>>>> imported the environments into foreman. When I go to edit the ntp class
>>>> parameter, I see all parameters from both environments. When I filter only
>>>> the production environment, I still see the two extra parameters from the
>>>> development module. Then I deleted the development environment from
>>>> Foreman, remove the contents from the filesystem. Then viewed the
>>>> parameters for the class and still see the two extra parameters that's only
>>>> available in the development branch.
>>>>
>>>> What I expected was to keep my development and production
>>>> modules completely separate using foreman environments. When I want to test
>>>> a module, just change the host environment and issue a puppet run from
>>>> foreman.
>>>>
>>>> Is this not the expected behavior?
>>>>
>>>
>>> I'm really happy you bring this up :slight_smile: as we spent quite some time trying
>>> to figure out how to best address this.
>>>
>>> Foreman solution around parameters, is trying to solve two problems:
>>> 1. integrate with puppet ENC (e.g. the ability to tell puppet which
>>> class/params to use)
>>> 2. define the value of parameter to use
>>>
>>> Since we already had the concept of Smart variables, where a value can
>>> be automatically selected based of the host properties (e.g. for this
>>> domain, use this ntp value), we integrated the two.
>>>
>>> now, we were facing the question of:
>>> should smartvars (in their param classes nature) should be isolated per
>>> environment or not
>>>
>>> the benefits was
>>> - complete separation between environments
>>> the disadvantage however was:
>>> - you can't reuse values
>>> for example, if you have ntp server parameter, you would not be able to
>>> share value from prod and dev, even if they are the same.
>>>
>>> so instead, we decided we'll keep each parameter across environments,
>>> however, we'll define a few things
>>> a. keep a record of which env this param is relevant for
>>> b. allow you to override the value per env, in the same way you would
>>> override it per domain.
>>>
>>> This gives you from one hand flexibility, and the ability to see all
>>> possible values of a given parameter across all hosts, domains, env etc in
>>> one place.
>>> however, if you change the default value, you would change it too all
>>> systems.
>>>
>>> When you say you can see the parameter (when using the filter), isn't it
>>> greyed out?
>>>
>>
>> I think is was grayed out.
>>
>>
>>>
>>>
>>
>>>
>>
>>> Regarding parameters that don't get deleted, well, since its data, we
>>> did not feel comfortable that the import process can delete parameters and
>>> their values, allowing you to delete both the classes and their params
>>> manually if you want.
>>>
>>> what do you think?
>>>
>>> Ohad
>>>
>>>
>> When you remove a class you should have an option to remove any values
>> associated with its params. This allows for my use case, where I am only
>> using environments to separate puppet code I developing from puppet code
>> that can be applied to systems. This way an environment gets cleaned up
>> when a class is removed.
>>
>> Base on your reasons for reasons for keeping each parameter across
>> environments, I can imagine use cases where this works perfectly. An
>> explanation of the environment I'm trying to fit foreman with puppet into
>> is necessary to help understand why I think it should be separated.
>>
>> ****
>>
>> First we have locations: east, west; these are mapped perfectly to
>> (Foreman RC) Locations which are mapped to a hostgroup.
>>
>> ****
>>
>> Then we have various targets, RHEV, Vsphere, Physical, Openstack, which
>> maps perfectly to the "Deploy on" option when you build a new host.
>>
>> ****
>>
>> Take for example the Vsphere target, we have many clusters, datastores,
>> networks which maps perfectly to foreman's "Virtual Machine", "Operating
>> System", "Network". And Foreman allows for setting what these defaults
>> should be using a hostgroups.
>>
>> ****
>>
>> Finally where a host end up running is determined by the following:
>>
>> * Locations - East, West
>> * Environments - Dev, Test, Prod
>> * Teirs - (Dev: a, b c…) (Test: a, b, c…) and same for Prod
>> * Role - Jboss, Oracle, etc…
>> * Network - is determined by role, tier, environment
>>
>> With this in mind hostgroups seems like the best way to ensure a host
>> ends up running where it should. I could not figure out how to map things
>> into Puppet concept of environments, and then eventually Foreman. This is
>> how I arrive at the decision to use Puppet/Foreman environments only for
>> separating my puppet code. And for this use case, keeping classes separate
>> per environment makes sense.
>>
>> Here's the next issue, Foreman ties classes to environments and you can
>> only override a param in two places "Host" or "Pupept Class" -> "Smart
>> Class Parameter". From Smart parameter, you can apply a class to multiple
>> hostgroups which pretty much set some default params for all hostgroups
>> selected. Now you can make exceptions for select hostgroups or other paths
>> using the "Override Value For Specific Hosts". To me, this is fine for
>> users who mostly/only use Foreman as an ENC, but flawed for those who use
>> Foreman for complete host lifecycle.
>> I should be able to override puppet class param at the hostgroup level.
>> This way, I can setup my puppet class to accept a tier or role or even
>> environment as a parameter. Our view is; for normal Foreman parameters,
>> global and the ones you can create at the hostgroup level. These are only
>> relevant to things, like snippets, and provision templates. And these are
>> usually only applicable when you kickstart/pxe boot a host. If you are
>> building a host from an image, then most of the things you want to do with
>> it (place in the correct cluster, network, domain) Foreman already does
>> well. Once its online, majority if not all the things I want to do can be
>> done using puppet. This makes setting puppet class param at the hostgroup
>> level ideal for us.
>>
>> I think there are two issues here:
>
> 1. we should have override class params in the hostgroup page too, afair,
> there is an open issue for that.
>
yes

> 2. you want to have per compute resource defaults, such as Hostgroup XYZ
> running on vsphere in location ZZZ should get this hw profile as default?
>

This may be another issue, but in Foreman RC1, there's no option to use a
Vsphere template/image with vsphere compute resource. So I am not sure if
this is just a issue with my setup or it does not exist at all. If it does
not exist at all, then yes this is issue #2.

And this should be extended to other things as well, I should be able to
set compute resource defaults at the hostgroup level. This way a operator
who decides to deploy on Vmware for example, selects the "Vmware-jboss-a"
hostgroup, the "Virtual Machine", cluster, data store, network(vlan)
should be populated from the selection of the hostgroup.

This also simplify my api calls for building host if these defaults are at
the hostgroup level.

··· On Thursday, January 3, 2013 2:24:01 AM UTC-5, ohad wrote: > On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron <swy...@gmail.com > > wrote: >> On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: >>> On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote:

>
>
>
>>
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I'm just starting out with git, puppet and foreman, and I'm interested
>>>>> in using puppet environments for separating puppet modules I'm developing
>>>>> or making changes to from ready to use modules.
>>>>>
>>>>> I created a ntp module using parameterized classes, then created two
>>>>> git branches dev and prod. I added two extra parameters to the development
>>>>> ntp module branch. Setup the puppet.conf with the environment paths and
>>>>> imported the environments into foreman. When I go to edit the ntp class
>>>>> parameter, I see all parameters from both environments. When I filter only
>>>>> the production environment, I still see the two extra parameters from the
>>>>> development module. Then I deleted the development environment from
>>>>> Foreman, remove the contents from the filesystem. Then viewed the
>>>>> parameters for the class and still see the two extra parameters that's only
>>>>> available in the development branch.
>>>>>
>>>>> What I expected was to keep my development and production
>>>>> modules completely separate using foreman environments. When I want to test
>>>>> a module, just change the host environment and issue a puppet run from
>>>>> foreman.
>>>>>
>>>>> Is this not the expected behavior?
>>>>>
>>>>
>>>> I'm really happy you bring this up :slight_smile: as we spent quite some time
>>>> trying to figure out how to best address this.
>>>>
>>>> Foreman solution around parameters, is trying to solve two problems:
>>>> 1. integrate with puppet ENC (e.g. the ability to tell puppet which
>>>> class/params to use)
>>>> 2. define the value of parameter to use
>>>>
>>>> Since we already had the concept of Smart variables, where a value can
>>>> be automatically selected based of the host properties (e.g. for this
>>>> domain, use this ntp value), we integrated the two.
>>>>
>>>> now, we were facing the question of:
>>>> should smartvars (in their param classes nature) should be isolated
>>>> per environment or not
>>>>
>>>> the benefits was
>>>> - complete separation between environments
>>>> the disadvantage however was:
>>>> - you can't reuse values
>>>> for example, if you have ntp server parameter, you would not be able to
>>>> share value from prod and dev, even if they are the same.
>>>>
>>>> so instead, we decided we'll keep each parameter across environments,
>>>> however, we'll define a few things
>>>> a. keep a record of which env this param is relevant for
>>>> b. allow you to override the value per env, in the same way you would
>>>> override it per domain.
>>>>
>>>> This gives you from one hand flexibility, and the ability to see all
>>>> possible values of a given parameter across all hosts, domains, env etc in
>>>> one place.
>>>> however, if you change the default value, you would change it too all
>>>> systems.
>>>>
>>>> When you say you can see the parameter (when using the filter), isn't
>>>> it greyed out?
>>>>
>>>
>>> I think is was grayed out.
>>>
>>>
>>>>
>>>>
>>>
>>>>
>>>
>>>> Regarding parameters that don't get deleted, well, since its data, we
>>>> did not feel comfortable that the import process can delete parameters and
>>>> their values, allowing you to delete both the classes and their params
>>>> manually if you want.
>>>>
>>>> what do you think?
>>>>
>>>> Ohad
>>>>
>>>>
>>> When you remove a class you should have an option to remove any values
>>> associated with its params. This allows for my use case, where I am only
>>> using environments to separate puppet code I developing from puppet code
>>> that can be applied to systems. This way an environment gets cleaned up
>>> when a class is removed.
>>>
>>> Base on your reasons for reasons for keeping each parameter across
>>> environments, I can imagine use cases where this works perfectly. An
>>> explanation of the environment I'm trying to fit foreman with puppet into
>>> is necessary to help understand why I think it should be separated.
>>>
>>> ****
>>>
>>> First we have locations: east, west; these are mapped perfectly to
>>> (Foreman RC) Locations which are mapped to a hostgroup.
>>>
>>> ****
>>>
>>> Then we have various targets, RHEV, Vsphere, Physical, Openstack, which
>>> maps perfectly to the "Deploy on" option when you build a new host.
>>>
>>> ****
>>>
>>> Take for example the Vsphere target, we have many clusters, datastores,
>>> networks which maps perfectly to foreman's "Virtual Machine", "Operating
>>> System", "Network". And Foreman allows for setting what these defaults
>>> should be using a hostgroups.
>>>
>>> ****
>>>
>>> Finally where a host end up running is determined by the following:
>>>
>>> * Locations - East, West
>>> * Environments - Dev, Test, Prod
>>> * Teirs - (Dev: a, b c…) (Test: a, b, c…) and same for Prod
>>> * Role - Jboss, Oracle, etc…
>>> * Network - is determined by role, tier, environment
>>>
>>> With this in mind hostgroups seems like the best way to ensure a host
>>> ends up running where it should. I could not figure out how to map things
>>> into Puppet concept of environments, and then eventually Foreman. This is
>>> how I arrive at the decision to use Puppet/Foreman environments only for
>>> separating my puppet code. And for this use case, keeping classes separate
>>> per environment makes sense.
>>>
>>> Here's the next issue, Foreman ties classes to environments and you can
>>> only override a param in two places "Host" or "Pupept Class" -> "Smart
>>> Class Parameter". From Smart parameter, you can apply a class to multiple
>>> hostgroups which pretty much set some default params for all hostgroups
>>> selected. Now you can make exceptions for select hostgroups or other paths
>>> using the "Override Value For Specific Hosts". To me, this is fine for
>>> users who mostly/only use Foreman as an ENC, but flawed for those who use
>>> Foreman for complete host lifecycle.
>>> I should be able to override puppet class param at the hostgroup level.
>>> This way, I can setup my puppet class to accept a tier or role or even
>>> environment as a parameter. Our view is; for normal Foreman parameters,
>>> global and the ones you can create at the hostgroup level. These are only
>>> relevant to things, like snippets, and provision templates. And these are
>>> usually only applicable when you kickstart/pxe boot a host. If you are
>>> building a host from an image, then most of the things you want to do with
>>> it (place in the correct cluster, network, domain) Foreman already does
>>> well. Once its online, majority if not all the things I want to do can be
>>> done using puppet. This makes setting puppet class param at the hostgroup
>>> level ideal for us.
>>>
>>> I think there are two issues here:
>>
>> 1. we should have override class params in the hostgroup page too, afair,
>> there is an open issue for that.
>>
> yes
>
>
>> 2. you want to have per compute resource defaults, such as Hostgroup XYZ
>> running on vsphere in location ZZZ should get this hw profile as default?
>>
>
> This may be another issue, but in Foreman RC1, there's no option to use a
> Vsphere template/image with vsphere compute resource. So I am not sure if
> this is just a issue with my setup or it does not exist at all. If it does
> not exist at all, then yes this is issue #2.
>
> we currently pxeboot vsphere (just like libvirt), once we have a common
solution to use images (like we do on openstack/ec2/rackspace) we should be
able to support it in ovirt,vsphere and libvirt.

··· On Thu, Jan 3, 2013 at 3:42 PM, Rodrique Heron wrote: > On Thursday, January 3, 2013 2:24:01 AM UTC-5, ohad wrote: >> On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron wrote: >>> On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: >>>> On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote:

And this should be extended to other things as well, I should be able to
set compute resource defaults at the hostgroup level. This way a operator
who decides to deploy on Vmware for example, selects the "Vmware-jboss-a"
hostgroup, the “Virtual Machine”, cluster, data store, network(vlan)
should be populated from the selection of the hostgroup.

This also simplify my api calls for building host if these defaults are at
the hostgroup level.

I agree… patches are welcomed! :slight_smile:


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/s-zgdksQaawJ.

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.

As soon as I learn some ruby and about rails development, I'll definitely
contribute.

··· On Thursday, January 3, 2013 8:50:09 AM UTC-5, ohad wrote: > > > > > On Thu, Jan 3, 2013 at 3:42 PM, Rodrique Heron <swy...@gmail.com > > wrote: > >> >> >> On Thursday, January 3, 2013 2:24:01 AM UTC-5, ohad wrote: >> >>> >>> >>> >>> On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron wrote: >>> >>>> >>>> >>>> On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote: >>>>> >>>>>> I'm just starting out with git, puppet and foreman, and I'm >>>>>> interested in using puppet environments for separating puppet modules I'm >>>>>> developing or making changes to from ready to use modules. >>>>>> >>>>>> I created a ntp module using parameterized classes, then created two >>>>>> git branches dev and prod. I added two extra parameters to the development >>>>>> ntp module branch. Setup the puppet.conf with the environment paths and >>>>>> imported the environments into foreman. When I go to edit the ntp class >>>>>> parameter, I see all parameters from both environments. When I filter only >>>>>> the production environment, I still see the two extra parameters from the >>>>>> development module. Then I deleted the development environment from >>>>>> Foreman, remove the contents from the filesystem. Then viewed the >>>>>> parameters for the class and still see the two extra parameters that's only >>>>>> available in the development branch. >>>>>> >>>>>> What I expected was to keep my development and production >>>>>> modules completely separate using foreman environments. When I want to test >>>>>> a module, just change the host environment and issue a puppet run from >>>>>> foreman. >>>>>> >>>>>> Is this not the expected behavior? >>>>>> >>>>> >>>>> I'm really happy you bring this up :) as we spent quite some time >>>>> trying to figure out how to best address this. >>>>> >>>>> Foreman solution around parameters, is trying to solve two problems: >>>>> 1. integrate with puppet ENC (e.g. the ability to tell puppet which >>>>> class/params to use) >>>>> 2. define the value of parameter to use >>>>> >>>>> Since we already had the concept of Smart variables, where a value can >>>>> be automatically selected based of the host properties (e.g. for this >>>>> domain, use this ntp value), we integrated the two. >>>>> >>>>> now, we were facing the question of: >>>>> should smartvars (in their param classes nature) should be isolated >>>>> per environment or not >>>>> >>>>> the benefits was >>>>> - complete separation between environments >>>>> the disadvantage however was: >>>>> - you can't reuse values >>>>> for example, if you have ntp server parameter, you would not be able >>>>> to share value from prod and dev, even if they are the same. >>>>> >>>>> so instead, we decided we'll keep each parameter across environments, >>>>> however, we'll define a few things >>>>> a. keep a record of which env this param is relevant for >>>>> b. allow you to override the value per env, in the same way you would >>>>> override it per domain. >>>>> >>>>> This gives you from one hand flexibility, and the ability to see all >>>>> possible values of a given parameter across all hosts, domains, env etc in >>>>> one place. >>>>> however, if you change the default value, you would change it too all >>>>> systems. >>>>> >>>>> When you say you can see the parameter (when using the filter), isn't >>>>> it greyed out? >>>>> >>>> >>>> I think is was grayed out. >>>> >>>> >>>>> >>>>> >>>> >>>>> >>>> >>>>> Regarding parameters that don't get deleted, well, since its data, we >>>>> did not feel comfortable that the import process can delete parameters and >>>>> their values, allowing you to delete both the classes and their params >>>>> manually if you want. >>>>> >>>>> what do you think? >>>>> >>>>> Ohad >>>>> >>>>> >>>> When you remove a class you should have an option to remove any values >>>> associated with its params. This allows for my use case, where I am only >>>> using environments to separate puppet code I developing from puppet code >>>> that can be applied to systems. This way an environment gets cleaned up >>>> when a class is removed. >>>> >>>> Base on your reasons for reasons for keeping each parameter across >>>> environments, I can imagine use cases where this works perfectly. An >>>> explanation of the environment I'm trying to fit foreman with puppet into >>>> is necessary to help understand why I think it should be separated. >>>> >>>> **** >>>> >>>> First we have locations: east, west; these are mapped perfectly to >>>> (Foreman RC) Locations which are mapped to a hostgroup. >>>> >>>> **** >>>> >>>> Then we have various targets, RHEV, Vsphere, Physical, Openstack, which >>>> maps perfectly to the "Deploy on" option when you build a new host. >>>> >>>> **** >>>> >>>> Take for example the Vsphere target, we have many clusters, datastores, >>>> networks which maps perfectly to foreman's "Virtual Machine", "Operating >>>> System", "Network". And Foreman allows for setting what these defaults >>>> should be using a hostgroups. >>>> >>>> **** >>>> >>>> Finally where a host end up running is determined by the following: >>>> >>>> * Locations - East, West >>>> * Environments - Dev, Test, Prod >>>> * Teirs - (Dev: a, b c..) (Test: a, b, c..) and same for Prod >>>> * Role - Jboss, Oracle, etc.. >>>> * Network - is determined by role, tier, environment >>>> >>>> With this in mind hostgroups seems like the best way to ensure a host >>>> ends up running where it should. I could not figure out how to map things >>>> into Puppet concept of environments, and then eventually Foreman. This is >>>> how I arrive at the decision to use Puppet/Foreman environments only for >>>> separating my puppet code. And for this use case, keeping classes separate >>>> per environment makes sense. >>>> >>>> Here's the next issue, Foreman ties classes to environments and you can >>>> only override a param in two places "Host" or "Pupept Class" -> "Smart >>>> Class Parameter". From Smart parameter, you can apply a class to multiple >>>> hostgroups which pretty much set some default params for all hostgroups >>>> selected. Now you can make exceptions for select hostgroups or other paths >>>> using the "Override Value For Specific Hosts". To me, this is fine for >>>> users who mostly/only use Foreman as an ENC, but flawed for those who use >>>> Foreman for complete host lifecycle. >>>> I should be able to override puppet class param at the hostgroup level. >>>> This way, I can setup my puppet class to accept a tier or role or even >>>> environment as a parameter. Our view is; for normal Foreman parameters, >>>> global and the ones you can create at the hostgroup level. These are only >>>> relevant to things, like snippets, and provision templates. And these are >>>> usually only applicable when you kickstart/pxe boot a host. If you are >>>> building a host from an image, then most of the things you want to do with >>>> it (place in the correct cluster, network, domain) Foreman already does >>>> well. Once its online, majority if not all the things I want to do can be >>>> done using puppet. This makes setting puppet class param at the hostgroup >>>> level ideal for us. >>>> >>>> I think there are two issues here: >>> >>> 1. we should have override class params in the hostgroup page too, >>> afair, there is an open issue for that. >>> >> yes >> >> >>> 2. you want to have per compute resource defaults, such as Hostgroup XYZ >>> running on vsphere in location ZZZ should get this hw profile as default? >>> >> >> This may be another issue, but in Foreman RC1, there's no option to use >> a Vsphere template/image with vsphere compute resource. So I am not sure if >> this is just a issue with my setup or it does not exist at all. If it does >> not exist at all, then yes this is issue #2. >> >> we currently pxeboot vsphere (just like libvirt), once we have a common > solution to use images (like we do on openstack/ec2/rackspace) we should be > able to support it in ovirt,vsphere and libvirt. > > >> And this should be extended to other things as well, I should be able to >> set compute resource defaults at the hostgroup level. This way a operator >> who decides to deploy on Vmware for example, selects the "Vmware-jboss-a" >> hostgroup, the "Virtual Machine", cluster, data store, network(vlan) >> should be populated from the selection of the hostgroup. >> >> This also simplify my api calls for building host if these defaults are >> at the hostgroup level. >> >> I agree... patches are welcomed! :) >

Ohad,

What's the issue with building from a Vmware template, just like you can
using Ovirt?

··· On Thursday, January 3, 2013 9:09:56 AM UTC-5, Rodrique Heron wrote: > > > > On Thursday, January 3, 2013 8:50:09 AM UTC-5, ohad wrote: >> >> >> >> >> On Thu, Jan 3, 2013 at 3:42 PM, Rodrique Heron wrote: >> >>> >>> >>> On Thursday, January 3, 2013 2:24:01 AM UTC-5, ohad wrote: >>> >>>> >>>> >>>> >>>> On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron wrote: >>>> >>>>> >>>>> >>>>> On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron wrote: >>>>>> >>>>>>> I'm just starting out with git, puppet and foreman, and I'm >>>>>>> interested in using puppet environments for separating puppet modules I'm >>>>>>> developing or making changes to from ready to use modules. >>>>>>> >>>>>>> I created a ntp module using parameterized classes, then created two >>>>>>> git branches dev and prod. I added two extra parameters to the development >>>>>>> ntp module branch. Setup the puppet.conf with the environment paths and >>>>>>> imported the environments into foreman. When I go to edit the ntp class >>>>>>> parameter, I see all parameters from both environments. When I filter only >>>>>>> the production environment, I still see the two extra parameters from the >>>>>>> development module. Then I deleted the development environment from >>>>>>> Foreman, remove the contents from the filesystem. Then viewed the >>>>>>> parameters for the class and still see the two extra parameters that's only >>>>>>> available in the development branch. >>>>>>> >>>>>>> What I expected was to keep my development and production >>>>>>> modules completely separate using foreman environments. When I want to test >>>>>>> a module, just change the host environment and issue a puppet run from >>>>>>> foreman. >>>>>>> >>>>>>> Is this not the expected behavior? >>>>>>> >>>>>> >>>>>> I'm really happy you bring this up :) as we spent quite some time >>>>>> trying to figure out how to best address this. >>>>>> >>>>>> Foreman solution around parameters, is trying to solve two problems: >>>>>> 1. integrate with puppet ENC (e.g. the ability to tell puppet which >>>>>> class/params to use) >>>>>> 2. define the value of parameter to use >>>>>> >>>>>> Since we already had the concept of Smart variables, where a value >>>>>> can be automatically selected based of the host properties (e.g. for this >>>>>> domain, use this ntp value), we integrated the two. >>>>>> >>>>>> now, we were facing the question of: >>>>>> should smartvars (in their param classes nature) should be isolated >>>>>> per environment or not >>>>>> >>>>>> the benefits was >>>>>> - complete separation between environments >>>>>> the disadvantage however was: >>>>>> - you can't reuse values >>>>>> for example, if you have ntp server parameter, you would not be able >>>>>> to share value from prod and dev, even if they are the same. >>>>>> >>>>>> so instead, we decided we'll keep each parameter across environments, >>>>>> however, we'll define a few things >>>>>> a. keep a record of which env this param is relevant for >>>>>> b. allow you to override the value per env, in the same way you would >>>>>> override it per domain. >>>>>> >>>>>> This gives you from one hand flexibility, and the ability to see all >>>>>> possible values of a given parameter across all hosts, domains, env etc in >>>>>> one place. >>>>>> however, if you change the default value, you would change it too all >>>>>> systems. >>>>>> >>>>>> When you say you can see the parameter (when using the filter), isn't >>>>>> it greyed out? >>>>>> >>>>> >>>>> I think is was grayed out. >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Regarding parameters that don't get deleted, well, since its data, we >>>>>> did not feel comfortable that the import process can delete parameters and >>>>>> their values, allowing you to delete both the classes and their params >>>>>> manually if you want. >>>>>> >>>>>> what do you think? >>>>>> >>>>>> Ohad >>>>>> >>>>>> >>>>> When you remove a class you should have an option to remove any values >>>>> associated with its params. This allows for my use case, where I am only >>>>> using environments to separate puppet code I developing from puppet code >>>>> that can be applied to systems. This way an environment gets cleaned up >>>>> when a class is removed. >>>>> >>>>> Base on your reasons for reasons for keeping each parameter across >>>>> environments, I can imagine use cases where this works perfectly. An >>>>> explanation of the environment I'm trying to fit foreman with puppet into >>>>> is necessary to help understand why I think it should be separated. >>>>> >>>>> **** >>>>> >>>>> First we have locations: east, west; these are mapped perfectly to >>>>> (Foreman RC) Locations which are mapped to a hostgroup. >>>>> >>>>> **** >>>>> >>>>> Then we have various targets, RHEV, Vsphere, Physical, Openstack, >>>>> which maps perfectly to the "Deploy on" option when you build a new host. >>>>> >>>>> **** >>>>> >>>>> Take for example the Vsphere target, we have many clusters, >>>>> datastores, networks which maps perfectly to foreman's "Virtual Machine", >>>>> "Operating System", "Network". And Foreman allows for setting what these >>>>> defaults should be using a hostgroups. >>>>> >>>>> **** >>>>> >>>>> Finally where a host end up running is determined by the following: >>>>> >>>>> * Locations - East, West >>>>> * Environments - Dev, Test, Prod >>>>> * Teirs - (Dev: a, b c..) (Test: a, b, c..) and same for Prod >>>>> * Role - Jboss, Oracle, etc.. >>>>> * Network - is determined by role, tier, environment >>>>> >>>>> With this in mind hostgroups seems like the best way to ensure a host >>>>> ends up running where it should. I could not figure out how to map things >>>>> into Puppet concept of environments, and then eventually Foreman. This is >>>>> how I arrive at the decision to use Puppet/Foreman environments only for >>>>> separating my puppet code. And for this use case, keeping classes separate >>>>> per environment makes sense. >>>>> >>>>> Here's the next issue, Foreman ties classes to environments and you >>>>> can only override a param in two places "Host" or "Pupept Class" -> "Smart >>>>> Class Parameter". From Smart parameter, you can apply a class to multiple >>>>> hostgroups which pretty much set some default params for all hostgroups >>>>> selected. Now you can make exceptions for select hostgroups or other paths >>>>> using the "Override Value For Specific Hosts". To me, this is fine for >>>>> users who mostly/only use Foreman as an ENC, but flawed for those who use >>>>> Foreman for complete host lifecycle. >>>>> I should be able to override puppet class param at the hostgroup >>>>> level. This way, I can setup my puppet class to accept a tier or role or >>>>> even environment as a parameter. Our view is; for normal Foreman >>>>> parameters, global and the ones you can create at the hostgroup level. >>>>> These are only relevant to things, like snippets, and provision templates. >>>>> And these are usually only applicable when you kickstart/pxe boot a host. >>>>> If you are building a host from an image, then most of the things you want >>>>> to do with it (place in the correct cluster, network, domain) Foreman >>>>> already does well. Once its online, majority if not all the things I want >>>>> to do can be done using puppet. This makes setting puppet class param at >>>>> the hostgroup level ideal for us. >>>>> >>>>> I think there are two issues here: >>>> >>>> 1. we should have override class params in the hostgroup page too, >>>> afair, there is an open issue for that. >>>> >>> yes >>> >>> >>>> 2. you want to have per compute resource defaults, such as Hostgroup >>>> XYZ running on vsphere in location ZZZ should get this hw profile as >>>> default? >>>> >>> >>> This may be another issue, but in Foreman RC1, there's no option to use >>> a Vsphere template/image with vsphere compute resource. So I am not sure if >>> this is just a issue with my setup or it does not exist at all. If it does >>> not exist at all, then yes this is issue #2. >>> >>> we currently pxeboot vsphere (just like libvirt), once we have a common >> solution to use images (like we do on openstack/ec2/rackspace) we should be >> able to support it in ovirt,vsphere and libvirt. >> >> >>> And this should be extended to other things as well, I should be able to >>> set compute resource defaults at the hostgroup level. This way a operator >>> who decides to deploy on Vmware for example, selects the "Vmware-jboss-a" >>> hostgroup, the "Virtual Machine", cluster, data store, network(vlan) >>> should be populated from the selection of the hostgroup. >>> >>> This also simplify my api calls for building host if these defaults are >>> at the hostgroup level. >>> >>> I agree... patches are welcomed! :) >> > > As soon as I learn some ruby and about rails development, I'll definitely > contribute. >

> Ohad,
>
> What's the issue with building from a Vmware template, just like you can
> using Ovirt?
>

Ovirt template actually means hw profile + virtual disk image, but we only
use the hw profile part and pxe boot it and ignore the disk content.

Ohad

··· On Thu, Jan 3, 2013 at 5:41 PM, Rodrique Heron wrote:

On Thursday, January 3, 2013 9:09:56 AM UTC-5, Rodrique Heron wrote:

On Thursday, January 3, 2013 8:50:09 AM UTC-5, ohad wrote:

On Thu, Jan 3, 2013 at 3:42 PM, Rodrique Heron swy...@gmail.com wrote:

On Thursday, January 3, 2013 2:24:01 AM UTC-5, ohad wrote:

On Thu, Jan 3, 2013 at 6:44 AM, Rodrique Heron swy...@gmail.comwrote:

On Wednesday, January 2, 2013 4:01:45 AM UTC-5, ohad wrote:

On Tue, Jan 1, 2013 at 8:48 PM, Rodrique Heron swy...@gmail.comwrote:

I’m just starting out with git, puppet and foreman, and I’m
interested in using puppet environments for separating puppet modules I’m
developing or making changes to from ready to use modules.

I created a ntp module using parameterized classes, then created
two git branches dev and prod. I added two extra parameters to the
development ntp module branch. Setup the puppet.conf with the environment
paths and imported the environments into foreman. When I go to edit the
ntp class parameter, I see all parameters from both environments. When I
filter only the production environment, I still see the two extra
parameters from the development module. Then I deleted the development
environment from Foreman, remove the contents from the filesystem. Then
viewed the parameters for the class and still see the two extra parameters
that’s only available in the development branch.

What I expected was to keep my development and production
modules completely separate using foreman environments. When I want to test
a module, just change the host environment and issue a puppet run from
foreman.

Is this not the expected behavior?

I’m really happy you bring this up :slight_smile: as we spent quite some time
trying to figure out how to best address this.

Foreman solution around parameters, is trying to solve two problems:

  1. integrate with puppet ENC (e.g. the ability to tell puppet which
    class/params to use)
  2. define the value of parameter to use

Since we already had the concept of Smart variables, where a value
can be automatically selected based of the host properties (e.g. for this
domain, use this ntp value), we integrated the two.

now, we were facing the question of:
should smartvars (in their param classes nature) should be isolated
per environment or not

the benefits was

  • complete separation between environments
    the disadvantage however was:
  • you can’t reuse values
    for example, if you have ntp server parameter, you would not be able
    to share value from prod and dev, even if they are the same.

so instead, we decided we’ll keep each parameter across
environments, however, we’ll define a few things
a. keep a record of which env this param is relevant for
b. allow you to override the value per env, in the same way you
would override it per domain.

This gives you from one hand flexibility, and the ability to see all
possible values of a given parameter across all hosts, domains, env etc in
one place.
however, if you change the default value, you would change it too
all systems.

When you say you can see the parameter (when using the filter),
isn’t it greyed out?

I think is was grayed out.

Regarding parameters that don’t get deleted, well, since its data,
we did not feel comfortable that the import process can delete parameters
and their values, allowing you to delete both the classes and their params
manually if you want.

what do you think?

Ohad

When you remove a class you should have an option to remove any
values associated with its params. This allows for my use case, where I am
only using environments to separate puppet code I developing from puppet
code that can be applied to systems. This way an environment gets cleaned
up when a class is removed.

Base on your reasons for reasons for keeping each parameter across
environments, I can imagine use cases where this works perfectly. An
explanation of the environment I’m trying to fit foreman with puppet into
is necessary to help understand why I think it should be separated.


First we have locations: east, west; these are mapped perfectly to
(Foreman RC) Locations which are mapped to a hostgroup.


Then we have various targets, RHEV, Vsphere, Physical, Openstack,
which maps perfectly to the “Deploy on” option when you build a new host.


Take for example the Vsphere target, we have many clusters,
datastores, networks which maps perfectly to foreman’s “Virtual Machine”,
“Operating System”, “Network”. And Foreman allows for setting what these
defaults should be using a hostgroups.


Finally where a host end up running is determined by the following:

  • Locations - East, West
  • Environments - Dev, Test, Prod
  • Teirs - (Dev: a, b c…) (Test: a, b, c…) and same for Prod
  • Role - Jboss, Oracle, etc…
  • Network - is determined by role, tier, environment

With this in mind hostgroups seems like the best way to ensure a host
ends up running where it should. I could not figure out how to map things
into Puppet concept of environments, and then eventually Foreman. This is
how I arrive at the decision to use Puppet/Foreman environments only for
separating my puppet code. And for this use case, keeping classes separate
per environment makes sense.

Here’s the next issue, Foreman ties classes to environments and you
can only override a param in two places “Host” or “Pupept Class” -> “Smart
Class Parameter”. From Smart parameter, you can apply a class to multiple
hostgroups which pretty much set some default params for all hostgroups
selected. Now you can make exceptions for select hostgroups or other paths
using the “Override Value For Specific Hosts”. To me, this is fine for
users who mostly/only use Foreman as an ENC, but flawed for those who use
Foreman for complete host lifecycle.
I should be able to override puppet class param at the hostgroup
level. This way, I can setup my puppet class to accept a tier or role or
even environment as a parameter. Our view is; for normal Foreman
parameters, global and the ones you can create at the hostgroup level.
These are only relevant to things, like snippets, and provision templates.
And these are usually only applicable when you kickstart/pxe boot a host.
If you are building a host from an image, then most of the things you want
to do with it (place in the correct cluster, network, domain) Foreman
already does well. Once its online, majority if not all the things I want
to do can be done using puppet. This makes setting puppet class param at
the hostgroup level ideal for us.

I think there are two issues here:

  1. we should have override class params in the hostgroup page too,
    afair, there is an open issue for that.

yes

  1. you want to have per compute resource defaults, such as Hostgroup
    XYZ running on vsphere in location ZZZ should get this hw profile as
    default?

This may be another issue, but in Foreman RC1, there’s no option to
use a Vsphere template/image with vsphere compute resource. So I am not
sure if this is just a issue with my setup or it does not exist at all. If
it does not exist at all, then yes this is issue #2.

we currently pxeboot vsphere (just like libvirt), once we have a common
solution to use images (like we do on openstack/ec2/rackspace) we should be
able to support it in ovirt,vsphere and libvirt.

And this should be extended to other things as well, I should be able
to set compute resource defaults at the hostgroup level. This way a
operator who decides to deploy on Vmware for example, selects the
"Vmware-jboss-a" hostgroup, the “Virtual Machine”, cluster, data store,
network(vlan) should be populated from the selection of the hostgroup.

This also simplify my api calls for building host if these defaults are
at the hostgroup level.

I agree… patches are welcomed! :slight_smile:

As soon as I learn some ruby and about rails development, I’ll definitely
contribute.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/gG6tqx2bb-IJ.

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.