>
>
>
>
>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>> 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.
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:
