Re: [Puppet Users] Puppet with Hiera - Custom variables

[Stephen]

Thank you very much for this. I have successfully tested it!

I perfer the idea of Puppet 'knowing' which yaml file to use by way of a 
passed variable, rather than having to read from disk for it (and if there 
is a way to do this, I'd like to hear it).

But your solution works and it's not complicated, so thank you :)

Kind regards,
Stephen


On Wednesday, 24 May 2017 15:51:38 UTC+1, Arnau wrote:
>
> Hi,
>
> I don't know if there's another (or better) way, but I use a custom fact 
> for the *environment*. Then you can tell hiera to use this new fact in 
> the hierarchy tree:
>
> As an example:
> node:
>
> /etc/facter/facts.d/local.yaml
> ---
> env: "prod"
>
> puppet server:
> /etc/puppet/hiera.yaml
>
> ---
> :backends:
>   - yaml
>   - eyaml
> :hierarchy:
>   - "%{environment}/hieradb/%{::env}/cert/%{::clientcert}"
>
>
> *Notice that %{environment} refers to puppet environemnt 
> . (In my case those 
> are the git branches that I create).*
>
>
> HTH,
> Arnau
>
>
> 2017-05-24 16:17 GMT+02:00 Stephen >:
>
>> Hello,
>>
>> At the moment I do not use Hiera to store any config at all, but I want 
>> to.
>>
>> Currently, I can use the variable "$mysettings::config::envtype" in my 
>> classes, as long as I put 'require mysettings::config' at the head of those 
>> classes.
>>
>> In my environment, I use this variable to hold "PROD", "DEV", "PERFTEST", 
>> "QA", etc (It derives this from IP subnet).
>>
>>
>> I have this in my hiera.yaml file, which successfully pulls the data 
>> from, for example, the *os/RedHat.yaml* file when needed.
>>   - name: "OS defaults"
>> path: "os/%{facts.os.family}.yaml"
>> 
>>
>> 
>> How do I use my variable above in the same way? I've tried the below, and 
>> a number of other syntaxes, and can't get it working. ie. I want to 
>> retrieve config from the *envtype/DEV.yaml* file, but it's not returning 
>> anything.
>>   - name: "Envtype data"
>> path: "envtype/%{'mysettings::config::envtype'}.yaml"
>> 
>>
>> Apologies if this is explained in documentation, I have gone over it and 
>> it's just not clicking for me. Should I be doing it this way, should I be 
>> using custom facts, should I be doing something else?
>>
>> I'm on Puppet PE v2017.1.0.
>>
>> Thanks for any help.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/c569bc63-69b5-481c-8f38-7e3388ea49a3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/48209bb7-1c96-4a51-abc1-7ca7ccc1bb95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet with Hiera - Custom variables

[Arnau]

Hi,

the typical scenario for running nodes in differnet environments is to use
r10k.
https://docs.puppet.com/pe/latest/r10k_run.html

git + r10k . It's a well known combo that works perefctly.

Best,
Arnau


2017-05-25 12:15 GMT+02:00 Stephen :

>
> Thank you very much for this. I have successfully tested it!
>
> I perfer the idea of Puppet 'knowing' which yaml file to use by way of a
> passed variable, rather than having to read from disk for it (and if there
> is a way to do this, I'd like to hear it).
>
> But your solution works and it's not complicated, so thank you :)
>
> Kind regards,
> Stephen
>
>
> On Wednesday, 24 May 2017 15:51:38 UTC+1, Arnau wrote:
>>
>> Hi,
>>
>> I don't know if there's another (or better) way, but I use a custom fact
>> for the *environment*. Then you can tell hiera to use this new fact in
>> the hierarchy tree:
>>
>> As an example:
>> node:
>>
>> /etc/facter/facts.d/local.yaml
>> ---
>> env: "prod"
>>
>> puppet server:
>> /etc/puppet/hiera.yaml
>>
>> ---
>> :backends:
>>   - yaml
>>   - eyaml
>> :hierarchy:
>>   - "%{environment}/hieradb/%{::env}/cert/%{::clientcert}"
>>
>>
>> *Notice that %{environment} refers to puppet environemnt
>> . (In my case those
>> are the git branches that I create).*
>>
>>
>> HTH,
>> Arnau
>>
>>
>> 2017-05-24 16:17 GMT+02:00 Stephen :
>>
>>> Hello,
>>>
>>> At the moment I do not use Hiera to store any config at all, but I want
>>> to.
>>>
>>> Currently, I can use the variable "$mysettings::config::envtype" in my
>>> classes, as long as I put 'require mysettings::config' at the head of those
>>> classes.
>>>
>>> In my environment, I use this variable to hold "PROD", "DEV",
>>> "PERFTEST", "QA", etc (It derives this from IP subnet).
>>>
>>>
>>> I have this in my hiera.yaml file, which successfully pulls the data
>>> from, for example, the *os/RedHat.yaml* file when needed.
>>>   - name: "OS defaults"
>>> path: "os/%{facts.os.family}.yaml"
>>>
>>>
>>>
>>> How do I use my variable above in the same way? I've tried the below,
>>> and a number of other syntaxes, and can't get it working. ie. I want to
>>> retrieve config from the *envtype/DEV.yaml* file, but it's not
>>> returning anything.
>>>   - name: "Envtype data"
>>> path: "envtype/%{'mysettings::config::envtype'}.yaml"
>>>
>>>
>>> Apologies if this is explained in documentation, I have gone over it and
>>> it's just not clicking for me. Should I be doing it this way, should I be
>>> using custom facts, should I be doing something else?
>>>
>>> I'm on Puppet PE v2017.1.0.
>>>
>>> Thanks for any help.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-users...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/puppet-users/c569bc63-69b5-481c-8f38-7e3388ea49a3%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/48209bb7-1c96-4a51-abc1-7ca7ccc1bb95%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAM69jx_FvJSZuMM0xEFjh-uzD22hiV6vEeyoTHmuSVhXGf3QrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Controlling Puppet class execution order with parameters.

[Harish Kothuri]

I'm using Puppet 3.8.7 and "require" didn't work.

I could make it work with following

class1($version='1.1.1'){
   include Class3
   .
   .
   .before => [Class["Class3"]]
}
class2($version='2.2.2'){
   include Class3
   .
   .   .before => [Class["Class3"]]
}

and 

class3()
{
exec{ 'something':
  cmd => 'some command here',
}
}



On Wednesday, May 24, 2017 at 9:27:40 PM UTC+5:30, Harish Kothuri wrote:
>
> Hi,
>
> I have 3 classes and i need to execute class 3 only when class 1 and class 
> 2 completes. All of these classes must be attached to a host.
>
> class1($version='1.1.1'){
>.
>.
>.
> }
> class2($version='2.2.2'){
>.
>.
>.
> }
>
> and 
>
> class3(){
> import class1
> import class2
>
> exec{ 'something':
>   cmd => 'some command here',
>   before => [Class['class1'], Class['class2']]
> }
> }
>
> When i try to apply the above relation, i get the following error
>
> *Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: Duplicate declaration: Class[class1] is already declared; cannot re 
> declare on node machine.domain.com *
>
> Can any one guide me how to handle this scenario?
>
> Thanks
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d42e6665-b03c-4b8f-96a6-b65fb66314c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Controlling Puppet class execution order with parameters.

[Arnau]

Hi,

https://puppet.com/blog/class-containment-puppet

I'd say
1.- one module for you stuuf (moduleA)
2.- one file per class
3.-) one class that "contain" the others and set order.

moduleA/class1.pp
class moduleA::class1 { }

moduleA/class2.pp
class moduleA::class2 { }

moduleaA/class3.pp
class moduleA::class3 { }


moduleA/init.pp
contain moduelA::class1
contain moduelA::class2
contain moduelA::class3

Class['moduelA::class1'] ->
Class['moduelA::class2'] ->
Class['moduelA::class3']


HTH,
Arnau

2017-05-24 17:57 GMT+02:00 Harish Kothuri :

> Hi,
>
> I have 3 classes and i need to execute class 3 only when class 1 and class
> 2 completes. All of these classes must be attached to a host.
>
> class1($version='1.1.1'){
>.
>.
>.
> }
> class2($version='2.2.2'){
>.
>.
>.
> }
>
> and
>
> class3(){
> import class1
> import class2
>
> exec{ 'something':
>   cmd => 'some command here',
>   before => [Class['class1'], Class['class2']]
> }
> }
>
> When i try to apply the above relation, i get the following error
>
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Duplicate declaration: Class[class1] is already declared; cannot re
> declare on node machine.domain.com *
>
> Can any one guide me how to handle this scenario?
>
> Thanks
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/5e5d0f57-5df3-43f5-8d96-48896ed258b2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAM69jx8nbaraMUNv9cmR24Xtenjx%3DKmWzVk4%2BCPLC-t1BJcPJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] migrating from calling_* in hiera 3 to hiera 5

[Henrik Lindberg]

On 24/05/17 18:41, Martin Alfke wrote:

Hi Rudy,

I don’t know whether someone already replied.
https://docs.puppet.com/puppet/4.10/hiera_migrate_v3_yaml.html#remove-hierarchy-levels-with-callingmodule-and-friends

Quote from the link:

Remove hierarchy levels with calling_module and friends

Hiera 3 could use three special pseudo-variables (which weren’t available in 
Puppet code) in its hierarchy:

• calling_module
• calling_class
• calling_class_path
Hiera.yaml version 5 doesn’t support these, so you must drop any hierarchy 
levels that interpolate them.

These variables were added to support a hacky predecessor of module data; 
anything you were doing with them is better accomplished with the module layer.

Martin



It is worth pointing out that using calling_module/class etc. is 
typically used to keep the data for a module/class (etc) in a separate 
file/directory and then interpolate to get it. Most users do not use 
these features for (the bad, anti-pattern) of binding the same key to 
different values depending on from where it is looked up (that is the 
main reason those keys are no longer supported, but it is also performance).


So - if not relying on the anti-pattern (which you should not), then all 
the values in all the referenced files can actually be bound at the same 
time and there is not need to differentiate on them using paths.


If there is a desire to keep data separate, they can be stored in 
separate files and the `glob` variant can be used to read all of them.
Say you want to be able to override different classes at the environment 
level - you could then create a directory called 'classes', and for each 
class you would have a data file in that directory. Each data file by 
convention would then only contain keys for that class. You then map all 
of them with a glob in your hiera.yaml.


If the purpose was to provide defaults, simply place a hiera.yaml in 
your module and keep the (default) data for the module there.


Hope that helps.
- henrik


On 16 May 2017, at 11:36, Rudy Gevaert  wrote:

And to add the current hiera.yaml (3)

# Managed with Puppet
---
:backends:
   - eyaml
   - yaml
:yaml:
   :datadir: "/etc/puppetlabs/code/environments/%{::environment}/hieradata"
:eyaml:
   :extension: 'yaml'
   :datadir: "/etc/puppetlabs/code/environments/%{::environment}/hieradata"
   :pkcs7_private_key: /etc/puppetlabs/eyaml/private_key.pkcs7.pem
   :pkcs7_public_key:  /etc/puppetlabs/eyaml/public_key.pkcs7.pem
:hierarchy:
   - "nodes/%{::trusted.certname}"
   - "application_tier/%{::application_tier}/%{calling_class}"
   - "application_tier/%{::application_tier}/%{calling_module}"
   - "application_tier/%{::application_tier}"
   - "classes/%{calling_class}"
   - "modules/%{calling_module}"
   - "environment/%{::environment}"
   - "serverbeheer"
   - "common"



On Tuesday, May 16, 2017 at 11:31:23 AM UTC+2, Rudy Gevaert wrote:
Hallo,

Now that I have upgraded to the latest Puppet version I have the task to 
upgrade our hiera setup.

Unfortunately we are heavily using calling_class and calling_module in our 
setup.  And although the documentation says currently hiera5 is backward 
compatible.  This doesn't work anymore.

I would like to know how I can easily upgrade to hiera5 without needing to 
change all the lookups at once.

Is there any way to do that?  Or shall I need to do this all at once?

For now it seems impossible to have a situation that I can work in a branch to 
test things about.  Because to change to Hiera5, (and so being able to test the 
new system) I immediately remove my ability to leave calling_* in the global 
hiera config.

Thanks in advance,

Rudy


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a2fc367f-b591-49fa-b810-a0af926a0d7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.





--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/og721d%2443q%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: apt/yum.downloads.puppetlabs.com CDN & rsync deprecation

[Morgan Rhodes]

Hi Andrew,

Looks like some files were accidentally synced out. They've been cleaned up
now.

On Wed, May 24, 2017 at 10:53 AM Melissa Stone  wrote:

> On Wed, May 24, 2017 at 10:49 AM Melissa Stone  wrote:
>
>> On Wed, May 24, 2017 at 4:16 AM Andrew Elwell 
>> wrote:
>>
>>>
>>>
>>> On Thursday, 27 April 2017 02:31:42 UTC+8, Daniel Dreier wrote:

 I'm sorry we broke people's rsync-based repository mirroring. I should
 have communicated this change well in advance. To get you all mirroring our
 repositories again, I've configured rsync.puppet.com. You can sync
 from it using a command like:

 rsync -av --copy-links --del rsync://rsync.puppet.com/packages/yum/
 /tmp/yum/
 rsync -av --copy-links --del rsync://rsync.puppet.com/packages/apt/
 /tmp/apt/

 Please let me know if you have any trouble with the new rsync service

>>>
>>> Yes.
>>>
>>> aelwell@galaxy-1:~$ rsync  rsync://rsync.puppet.com/packages/apt/dists/
>>> drwxrwxr-x  4,096 2017/01/18 09:05:57 .
>>> drwxrwxr-x  4,096 2015/11/13 08:51:24
>>> cumulus-20151112165122938545665
>>> drwxrwxr-x  4,096 2015/11/18 03:21:38
>>> cumulus-20151117105654400831046
>>> drwxrwxr-x  4,096 2015/11/18 08:27:29
>>> cumulus-20151117152326887946964
>>> drwxrwxr-x  4,096 2017/05/11 21:58:14 cumulus
>>> drwxrwxr-x  4,096 2017/05/11 21:58:14 huaweios
>>> drwxrwxr-x  4,096 2015/11/13 08:51:22
>>> jessie-20151112165118307861024
>>> drwxrwxr-x  4,096 2015/11/18 03:21:54
>>> jessie-20151117110350179683670
>>> drwxrwxr-x  4,096 2015/11/18 08:28:03
>>> jessie-20151117152857377466419
>>> drwxrwxr-x  4,096 2017/05/11 21:58:14 jessie
>>> etc
>>>
>>> it seems to be pulling in all your nightly builds which aren't visible
>>> in the web interface
>>> http://apt.puppetlabs.com/dists/
>>>
>> Hi Andrew,
>>
>> The nightly builds should be visible from the web interface (i.e.,
>> http://apt.puppetlabs.com/dists/trusty/puppet5-nightly/). We recently
>> added these nightly builds in to allow folks to test the new puppet5
>> platform. You can check out Eric0's blog post on the nightly repos at
>> https://puppet.com/blog/new-nightly-package-repositories-for-open-source-puppet
>>
>
> Ah, I see now you were asking about the freight directories that aren't
> visible (i.e., jessie-20151112165118307861024). We're digging into this now.
>
>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/0ebb5ec5-eaa3-414e-aeef-eb4eb7436687%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> *Melissa Stone*
>> release engineering
>> meli...@puppet.com | @melissaapiedra
>>
> --
> *Melissa Stone*
> release engineering
> meli...@puppet.com | @melissaapiedra
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAHEe_kqgtRE3OcAzaTODZkXVm%2BO%2BUuNfqQh7XyvOADqNduYwSw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Morgan Rhodes
mor...@puppet.com
Release Engineer

PuppetConf 2017 , 10-12 October
San Francisco, California
Save $328, register by 30 June w/ early adopter discount


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2BFnDv1YTpAEpt3jm0NWF_Dazk4%2BTB3aLMGkq_9iH%3Dy-efPKsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] r10K - Unable to understand the benefits of r10k dynamic environments..

[vishcurious]

We use Puppet, hiera, r10k with a number of forge modules, roles and 
profiles patterns to perform an automated deployment of a Java/NodeJS 
Application.

I find r10k to be very useful in fetching all dependent modules from a 
Puppetfile. However I am confused with the benefits of the r10k dynamic 
environments.
We have 8 environments, so we have created 8 branches in Git. The important 
feature is that all these 8 environments are identical except for heira 
properties.

Whenever we make a change in one of the puppet manifests(roles or 
profiles), we manually have to merge(sometimes cherry-pick)  these changes 
from 1 branch to the other, when we are ready to do a new deployment in 
another environment.

Managing code in 8 branches is appearing to be a time-consuming and 
 error-prone process to me. 
I am thinking of moving away from r10k dynamic environments usage and have 
only 1 branch (master). 
Whenever we deploy anything to Production env, we just tag the appropriate 
commit with a Git Tag.

I am thinking when the business application code that the development team 
are writing does not have a Git branch for every environment, why should 
R10K mandate that we create a branch for each environment?

I was wondering if any body has benefited from using R10k dynamic 
environments for automated deployment of an Application and can share their 
experience.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/34a74b0b-c4bc-465c-b521-19bdfbedc3f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] r10K - Unable to understand the benefits of r10k dynamic environments..

[Matthew Kennedy]

There are several ways dynamic environments can be helpful here is one I've
used to great effect.

Have three primary branches production, staging and development.  (or
release, snapshot and master.  The branches themselves don't matter)

Ensure that all production nodes use the production, staging use staging
and everything else uses development.

The general flow of things is that changes are pushed into development then
development is merged to staging and finally staging is merged to
production. At any time higher branches can be merged down, ie production
can always merge to staging.  In a perfect world changes would always
follow the normal flow and there won't be any commits in higher branches
that are now in all lower ones.  However people do things like push to
staging to fix a staging issue its a good idea to have merges to production
auto merge to development thereby closing the loop. This means that
production is always the oldest branch and all changes eventually make it
to it.

Scheduling wise the merge from development to staging could be automated
and very frequent, we used every day in the evening. Staging to production
occurred once a week and as needed. Pushes the development happened all the
time.

Intrinsic to this method though is that the branches are NOT strictly equal
to your internal 'environments'.  Many environments can use the development
dynamic puppet environment for example. You'll need to ensure you can set a
nodes puppet environment.  I know with enterprise there is some enforcement
of node environment to puppet environment but it is possible to break this.
Because of this we stopped referring to nodes being in an environment they
were in a 'tier' and mapped tiers to puppet environments.

Some benefits to this method.
Because the different branches are more like point in time versions of your
configuration you can do spot checks and/or regression checks against other
puppet environments. ie run against the staging puppet environment on a
production node or validate a change cutting a branch, pushing your change
there and running puppet against that branches puppet environment (cannot
understate how useful this is).

Visibility to what changes will occur on production.  We had a weekly 'go
through the changes from staging' meeting with Ops, Engineering and rel
event dev teams.

Relatively simple.

Some downsides.
If you are not disciplined and the branches diverge merges become long
painful events.  It is vital that the cycle is kept tight else you're going
to end up in a situation where the are merge conflicts and more importantly
lack of trust that the process works well. Do not allow weeks of work to
get 'stuck' at staging for example.

Hints
If possible work on feature/topic branches.  Always branch off of
production (unless you cant), because it is the oldest branch it should
always be possible to merge it back to any other primary branches without
bring along commits from newer branches.  Regularly merge production back
into so you don't get out-of-sync and try not to let a branch linger for
too long.  Then as you validate things merge to development, then merge to
staging and finally merge to production.  At that point all the commits
from the branch are in all three primary branches and you should be able to
delete the feature/topic branch. There are some issues still like half
baked things getting into production with the staging to production merge
but this avoids a lot of other issues.

Alternates
If protecting production from half finished work in staging branch is vital
it is possible to invert the flow and work with a purely feature/topic
based work flow. The staging and development branches are taken from
production then all features start as a branch off of production. Merges
from feature branches go to development, then staging and finally
production but there are never merges from staging to production or
development to staging. Because of this staging and development branches
can diverge (have commits that are not part of active features/topic
branches and not in production) which is bad. To solve this staging and
development branches should be periodically deleted and re-cut from
production. Then all active features/topic branches are merged back into
them. Ideally this should be automated. In addition all pushes to
development, staging and production should be denied (even for ops and
admins)... only merge requests should be permitted.

Anyways sorry for the novel


On Thu, May 25, 2017 at 4:34 PM  wrote:

> We use Puppet, hiera, r10k with a number of forge modules, roles and
> profiles patterns to perform an automated deployment of a Java/NodeJS
> Application.
>
> I find r10k to be very useful in fetching all dependent modules from a
> Puppetfile. However I am confused with the benefits of the r10k dynamic
> environments.
> We have 8 environments, so we have created 8 branches in Git. The
> important feature is that all these 8 environments are identic

Re: [Puppet Users] r10K - Unable to understand the benefits of r10k dynamic environments..

[Angel L. Mateo]

El 26/05/17 a las 01:34, vishcuri...@gmail.com escribió:
We use Puppet, hiera, r10k with a number of forge modules, roles and 
profiles patterns to perform an automated deployment of a Java/NodeJS 
Application.


I find r10k to be very useful in fetching all dependent modules from a 
Puppetfile. However I am confused with the benefits of the r10k dynamic 
environments.
We have 8 environments, so we have created 8 branches in Git. The 
important feature is that all these 8 environments are identical except 
for heira properties.


	I think this could be the "problem" (not a real problem). If your 8 
environments are the same except hiera properties, then I think you 
don't need 8 environments, but just one.


	You could create a fact indicating which of these 8 environments the 
node belongs to and modify your hiera hierarchy according to this new 
fact. This way you could use just one environment for all your nodes.


	And you could use dynamic environments when you need a dynamic one or 
when the difference between environments is more than just hiera.


--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 86337

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0fa6180e-a09f-9bd0-14b3-504bc4d5ffc2%40um.es.
For more options, visit https://groups.google.com/d/optout.