Re: [Puppet Users] Git Repo Strategy

[Luke Bigum]

Git doesn't work like that, the repo in it's entirety is at a certain commit / 
tag / version, so you can't do what I think you are asking.

You might find this useful. We went from monolithic to split modules over a 
year ago, here's the Bash that did it. You'll want to adjust certain things, 
like the module name prefix:


#! /bin/sh

MODULE=$1
BASE_DIR=$PWD
WORK_DIR="${BASE_DIR}/working"

CONTROL_REPO='lmax-controlrepo'
GIT_REPO_BASE='https://GITLABSERVER/GITLABGROUP/'

cat << EOF 
mkdir working
git clone ${GIT_REPO_BASE}/${CONTROL_REPO}.git ${WORK_DIR}/${CONTROL_REPO}
cd ${WORK_DIR}/${CONTROL_REPO}

git subtree split -P site/${MODULE} -b lmax-${MODULE}

cd ${WORK_DIR}
mkdir lmax-${MODULE}
cd lmax-${MODULE}
git init 
git pull ${WORK_DIR}/${CONTROL_REPO} lmax-${MODULE}

git remote add origin ${GIT_REPO_BASE}/lmax-${MODULE}.git
git push origin -u master

cd ${BASE_DIR}
EOF



--
Luke Bigum
Senior Systems Engineer

Information Systems

- Original Message -
From: "broncosd183" <saig...@gmail.com>
To: "puppet-users" <puppet-users@googlegroups.com>
Sent: Wednesday, 15 June, 2016 20:45:41
Subject: Re: [Puppet Users] Git Repo Strategy

EDIT: I've found this link by Gary which details how to change the 
basemodulepath for each environment.conf file to effectively read in a 
monolithic repo containing all of the desired modules in your puppetfile  ( 
http://garylarizza.com/blog/2014/03/07/puppet-workflow-part-3b/ ).  My 
modified question is once this has been implemented, is there any way to 
implement a more precise module control in the puppetfile i.e pass 
references or commit tags if the modules had been in individual repos?

On Wednesday, June 15, 2016 at 3:27:10 PM UTC-4, broncosd183 wrote:
>
> Hey all,
> I'm currently starting to implement the puppetfile format and have hit a 
> wall of sorts. We currently are stuck on that old monolithic repo of 
> modules and are eventually looking to move away from this sometime in the 
> near future. My question is, for now is there any way to make a puppetfile 
> for individual modules within this repo? We have hosted it on github and I 
> understand how to pass the url and references if the modules are in their 
> own repos. Can the same be done for modules in our monolithic repo? At the 
> very least we were hoping to make a puppetfile for the current repo 
> configuration and slowly transition out of it and update the puppetfile 
> accordingly. 
>
> Thanks!
>
> On Wednesday, June 15, 2016 at 11:35:33 AM UTC-4, Bret Wortman wrote:
>>
>> I made the conversion a little over a year ago and it's been a dream ever 
>> since. The Puppetfiles aren't that hard -- We store each module in its own 
>> repo and use branches to determine environments. For each new environment 
>> we want to use, we just branch the "puppet" repo which contains the 
>> Puppetfile and let it know which modules will be under test for this 
>> environment. It's a lot simpler than it sounds.
>>
>> On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote:
>>>
>>> Awesome thanks for the feedback and options Rich and Christopher. I'm 
>>> outlining a plan of attack now and going to make a pass at installing R10k 
>>> and configuring it correctly. The main hurdle was the puppetfile and its 
>>> dependencies; however, that looks much more feasible now.
>>>
>>> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:
>>>>
>>>> I'm assuming this could be done. We're talking about UNIX she'll 
>>>> commands and there's a way to do just about anything. But I can't imagine 
>>>> it being simple or fun to use. Like could you do Pull Requests on Github 
>>>> between these repos? Maybe, depending on how you set it up. People 
>>>> nowadays 
>>>> recommend against monolithic repos too, and that's what you'd have. You'd 
>>>> just have a bunch of them.
>>>>
>>>> The normal recommended workflow with r10k is using branches for those 
>>>> environments, not separate repos. Then you have the ability to merge 
>>>> between branches, so it's easy to promote those changes along your 
>>>> pipeline.
>>>>
>>>> I remember back before I started using r10k, it seemed very confusing 
>>>> to me. I think there's a bit more info out about it now. In terms of 
>>>> getting a Puppetfile setup, one of the hard things there is that you need 
>>>> to account for all of the dependencies. Rob Nelson made this cool Ruby gem 
>>>> that makes generating the file a bit easier. You can pass it a set of 
>>>> Forge 
>>>> modules and

Re: [Puppet Users] Git Repo Strategy

[broncosd183]

EDIT: I've found this link by Gary which details how to change the 
basemodulepath for each environment.conf file to effectively read in a 
monolithic repo containing all of the desired modules in your puppetfile  ( 
http://garylarizza.com/blog/2014/03/07/puppet-workflow-part-3b/ ).  My 
modified question is once this has been implemented, is there any way to 
implement a more precise module control in the puppetfile i.e pass 
references or commit tags if the modules had been in individual repos?

On Wednesday, June 15, 2016 at 3:27:10 PM UTC-4, broncosd183 wrote:
>
> Hey all,
> I'm currently starting to implement the puppetfile format and have hit a 
> wall of sorts. We currently are stuck on that old monolithic repo of 
> modules and are eventually looking to move away from this sometime in the 
> near future. My question is, for now is there any way to make a puppetfile 
> for individual modules within this repo? We have hosted it on github and I 
> understand how to pass the url and references if the modules are in their 
> own repos. Can the same be done for modules in our monolithic repo? At the 
> very least we were hoping to make a puppetfile for the current repo 
> configuration and slowly transition out of it and update the puppetfile 
> accordingly. 
>
> Thanks!
>
> On Wednesday, June 15, 2016 at 11:35:33 AM UTC-4, Bret Wortman wrote:
>>
>> I made the conversion a little over a year ago and it's been a dream ever 
>> since. The Puppetfiles aren't that hard -- We store each module in its own 
>> repo and use branches to determine environments. For each new environment 
>> we want to use, we just branch the "puppet" repo which contains the 
>> Puppetfile and let it know which modules will be under test for this 
>> environment. It's a lot simpler than it sounds.
>>
>> On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote:
>>>
>>> Awesome thanks for the feedback and options Rich and Christopher. I'm 
>>> outlining a plan of attack now and going to make a pass at installing R10k 
>>> and configuring it correctly. The main hurdle was the puppetfile and its 
>>> dependencies; however, that looks much more feasible now.
>>>
>>> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:

 I'm assuming this could be done. We're talking about UNIX she'll 
 commands and there's a way to do just about anything. But I can't imagine 
 it being simple or fun to use. Like could you do Pull Requests on Github 
 between these repos? Maybe, depending on how you set it up. People 
 nowadays 
 recommend against monolithic repos too, and that's what you'd have. You'd 
 just have a bunch of them.

 The normal recommended workflow with r10k is using branches for those 
 environments, not separate repos. Then you have the ability to merge 
 between branches, so it's easy to promote those changes along your 
 pipeline.

 I remember back before I started using r10k, it seemed very confusing 
 to me. I think there's a bit more info out about it now. In terms of 
 getting a Puppetfile setup, one of the hard things there is that you need 
 to account for all of the dependencies. Rob Nelson made this cool Ruby gem 
 that makes generating the file a bit easier. You can pass it a set of 
 Forge 
 modules and it will also include their dependencies:


 https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md

 It's pretty slick.

 Personally I'd recommend you stick it out and figure out how to make 
 r10k work for what you're doing. I would bet you'd be glad you did after. 
 If you have problems ask specific question here or IRC or Slack. There are 
 a lot of people using it now and there should be lots who can help.


 Rich 
 On Fri, Jun 10, 2016 at 7:34 AM Funsaized  wrote:

> Hello, 
>
> I am relatively new to puppet and am trying to develop a good workflow 
> in conjunction with git/github to keep a better version control system. 
> The 
> version of puppet that I am working with and has been implemented is a 
> bit 
> dated, and using R10k and developing a puppetfile would be quite time 
> consuming. I know that R10k and dynamic environments is the recommended 
> way 
> of doing things, though for now I'm not sure if its the best for my 
> scenario and how everything has been previously set up. My question is is 
> there a simple way to just map one git repo for each environment (dev, 
> QA, 
> production, etc). That way changes could be made in the dev environment, 
> then moved over to the correct repos when the changes are confirmed in 
> order? Would this be as simple as declaring each folder withing the 
> /puppet/environments folder as a git repo and controlling that way? 
>
> Deployment strategy
>
> -   Upload changes to 

Re: [Puppet Users] Git Repo Strategy

[broncosd183]

Hey all,
I'm currently starting to implement the puppetfile format and have hit a 
wall of sorts. We currently are stuck on that old monolithic repo of 
modules and are eventually looking to move away from this sometime in the 
near future. My question is, for now is there any way to make a puppetfile 
for individual modules within this repo? We have hosted it on github and I 
understand how to pass the url and references if the modules are in their 
own repos. Can the same be done for modules in our monolithic repo? At the 
very least we were hoping to make a puppetfile for the current repo 
configuration and slowly transition out of it and update the puppetfile 
accordingly. 

Thanks!

On Wednesday, June 15, 2016 at 11:35:33 AM UTC-4, Bret Wortman wrote:
>
> I made the conversion a little over a year ago and it's been a dream ever 
> since. The Puppetfiles aren't that hard -- We store each module in its own 
> repo and use branches to determine environments. For each new environment 
> we want to use, we just branch the "puppet" repo which contains the 
> Puppetfile and let it know which modules will be under test for this 
> environment. It's a lot simpler than it sounds.
>
> On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote:
>>
>> Awesome thanks for the feedback and options Rich and Christopher. I'm 
>> outlining a plan of attack now and going to make a pass at installing R10k 
>> and configuring it correctly. The main hurdle was the puppetfile and its 
>> dependencies; however, that looks much more feasible now.
>>
>> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:
>>>
>>> I'm assuming this could be done. We're talking about UNIX she'll 
>>> commands and there's a way to do just about anything. But I can't imagine 
>>> it being simple or fun to use. Like could you do Pull Requests on Github 
>>> between these repos? Maybe, depending on how you set it up. People nowadays 
>>> recommend against monolithic repos too, and that's what you'd have. You'd 
>>> just have a bunch of them.
>>>
>>> The normal recommended workflow with r10k is using branches for those 
>>> environments, not separate repos. Then you have the ability to merge 
>>> between branches, so it's easy to promote those changes along your pipeline.
>>>
>>> I remember back before I started using r10k, it seemed very confusing to 
>>> me. I think there's a bit more info out about it now. In terms of getting a 
>>> Puppetfile setup, one of the hard things there is that you need to account 
>>> for all of the dependencies. Rob Nelson made this cool Ruby gem that makes 
>>> generating the file a bit easier. You can pass it a set of Forge modules 
>>> and it will also include their dependencies:
>>>
>>>
>>> https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md
>>>
>>> It's pretty slick.
>>>
>>> Personally I'd recommend you stick it out and figure out how to make 
>>> r10k work for what you're doing. I would bet you'd be glad you did after. 
>>> If you have problems ask specific question here or IRC or Slack. There are 
>>> a lot of people using it now and there should be lots who can help.
>>>
>>>
>>> Rich 
>>> On Fri, Jun 10, 2016 at 7:34 AM Funsaized  wrote:
>>>
 Hello, 

 I am relatively new to puppet and am trying to develop a good workflow 
 in conjunction with git/github to keep a better version control system. 
 The 
 version of puppet that I am working with and has been implemented is a bit 
 dated, and using R10k and developing a puppetfile would be quite time 
 consuming. I know that R10k and dynamic environments is the recommended 
 way 
 of doing things, though for now I'm not sure if its the best for my 
 scenario and how everything has been previously set up. My question is is 
 there a simple way to just map one git repo for each environment (dev, QA, 
 production, etc). That way changes could be made in the dev environment, 
 then moved over to the correct repos when the changes are confirmed in 
 order? Would this be as simple as declaring each folder withing the 
 /puppet/environments folder as a git repo and controlling that way? 

 Deployment strategy

 -   Upload changes to Dev repo

 -   Deploy Dev changes to Dev master

 -   Test

 -   Merge Dev changes to QA repo

 -   Rinse and repeat

 -- 
 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com
  
 

Re: [Puppet Users] Git Repo Strategy

[Bret Wortman]

I made the conversion a little over a year ago and it's been a dream ever 
since. The Puppetfiles aren't that hard -- We store each module in its own 
repo and use branches to determine environments. For each new environment 
we want to use, we just branch the "puppet" repo which contains the 
Puppetfile and let it know which modules will be under test for this 
environment. It's a lot simpler than it sounds.

On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote:
>
> Awesome thanks for the feedback and options Rich and Christopher. I'm 
> outlining a plan of attack now and going to make a pass at installing R10k 
> and configuring it correctly. The main hurdle was the puppetfile and its 
> dependencies; however, that looks much more feasible now.
>
> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:
>>
>> I'm assuming this could be done. We're talking about UNIX she'll commands 
>> and there's a way to do just about anything. But I can't imagine it being 
>> simple or fun to use. Like could you do Pull Requests on Github between 
>> these repos? Maybe, depending on how you set it up. People nowadays 
>> recommend against monolithic repos too, and that's what you'd have. You'd 
>> just have a bunch of them.
>>
>> The normal recommended workflow with r10k is using branches for those 
>> environments, not separate repos. Then you have the ability to merge 
>> between branches, so it's easy to promote those changes along your pipeline.
>>
>> I remember back before I started using r10k, it seemed very confusing to 
>> me. I think there's a bit more info out about it now. In terms of getting a 
>> Puppetfile setup, one of the hard things there is that you need to account 
>> for all of the dependencies. Rob Nelson made this cool Ruby gem that makes 
>> generating the file a bit easier. You can pass it a set of Forge modules 
>> and it will also include their dependencies:
>>
>>
>> https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md
>>
>> It's pretty slick.
>>
>> Personally I'd recommend you stick it out and figure out how to make r10k 
>> work for what you're doing. I would bet you'd be glad you did after. If you 
>> have problems ask specific question here or IRC or Slack. There are a lot 
>> of people using it now and there should be lots who can help.
>>
>>
>> Rich 
>> On Fri, Jun 10, 2016 at 7:34 AM Funsaized  wrote:
>>
>>> Hello, 
>>>
>>> I am relatively new to puppet and am trying to develop a good workflow 
>>> in conjunction with git/github to keep a better version control system. The 
>>> version of puppet that I am working with and has been implemented is a bit 
>>> dated, and using R10k and developing a puppetfile would be quite time 
>>> consuming. I know that R10k and dynamic environments is the recommended way 
>>> of doing things, though for now I'm not sure if its the best for my 
>>> scenario and how everything has been previously set up. My question is is 
>>> there a simple way to just map one git repo for each environment (dev, QA, 
>>> production, etc). That way changes could be made in the dev environment, 
>>> then moved over to the correct repos when the changes are confirmed in 
>>> order? Would this be as simple as declaring each folder withing the 
>>> /puppet/environments folder as a git repo and controlling that way? 
>>>
>>> Deployment strategy
>>>
>>> -   Upload changes to Dev repo
>>>
>>> -   Deploy Dev changes to Dev master
>>>
>>> -   Test
>>>
>>> -   Merge Dev changes to QA repo
>>>
>>> -   Rinse and repeat
>>>
>>> -- 
>>> 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%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/089f1a64-6870-42fe-8d03-136446e0f475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[broncosd183]

Awesome thanks for the feedback and options Rich and Christopher. I'm 
outlining a plan of attack now and going to make a pass at installing R10k 
and configuring it correctly. The main hurdle was the puppetfile and its 
dependencies; however, that looks much more feasible now.

On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:
>
> I'm assuming this could be done. We're talking about UNIX she'll commands 
> and there's a way to do just about anything. But I can't imagine it being 
> simple or fun to use. Like could you do Pull Requests on Github between 
> these repos? Maybe, depending on how you set it up. People nowadays 
> recommend against monolithic repos too, and that's what you'd have. You'd 
> just have a bunch of them.
>
> The normal recommended workflow with r10k is using branches for those 
> environments, not separate repos. Then you have the ability to merge 
> between branches, so it's easy to promote those changes along your pipeline.
>
> I remember back before I started using r10k, it seemed very confusing to 
> me. I think there's a bit more info out about it now. In terms of getting a 
> Puppetfile setup, one of the hard things there is that you need to account 
> for all of the dependencies. Rob Nelson made this cool Ruby gem that makes 
> generating the file a bit easier. You can pass it a set of Forge modules 
> and it will also include their dependencies:
>
>
> https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md
>
> It's pretty slick.
>
> Personally I'd recommend you stick it out and figure out how to make r10k 
> work for what you're doing. I would bet you'd be glad you did after. If you 
> have problems ask specific question here or IRC or Slack. There are a lot 
> of people using it now and there should be lots who can help.
>
>
> Rich 
> On Fri, Jun 10, 2016 at 7:34 AM Funsaized  
> wrote:
>
>> Hello, 
>>
>> I am relatively new to puppet and am trying to develop a good workflow in 
>> conjunction with git/github to keep a better version control system. The 
>> version of puppet that I am working with and has been implemented is a bit 
>> dated, and using R10k and developing a puppetfile would be quite time 
>> consuming. I know that R10k and dynamic environments is the recommended way 
>> of doing things, though for now I'm not sure if its the best for my 
>> scenario and how everything has been previously set up. My question is is 
>> there a simple way to just map one git repo for each environment (dev, QA, 
>> production, etc). That way changes could be made in the dev environment, 
>> then moved over to the correct repos when the changes are confirmed in 
>> order? Would this be as simple as declaring each folder withing the 
>> /puppet/environments folder as a git repo and controlling that way? 
>>
>> Deployment strategy
>>
>> -   Upload changes to Dev repo
>>
>> -   Deploy Dev changes to Dev master
>>
>> -   Test
>>
>> -   Merge Dev changes to QA repo
>>
>> -   Rinse and repeat
>>
>> -- 
>> 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%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/4718ffec-64c2-4476-aba1-a9834f9d97f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Rich Burroughs]

I'm assuming this could be done. We're talking about UNIX she'll commands
and there's a way to do just about anything. But I can't imagine it being
simple or fun to use. Like could you do Pull Requests on Github between
these repos? Maybe, depending on how you set it up. People nowadays
recommend against monolithic repos too, and that's what you'd have. You'd
just have a bunch of them.

The normal recommended workflow with r10k is using branches for those
environments, not separate repos. Then you have the ability to merge
between branches, so it's easy to promote those changes along your pipeline.

I remember back before I started using r10k, it seemed very confusing to
me. I think there's a bit more info out about it now. In terms of getting a
Puppetfile setup, one of the hard things there is that you need to account
for all of the dependencies. Rob Nelson made this cool Ruby gem that makes
generating the file a bit easier. You can pass it a set of Forge modules
and it will also include their dependencies:

https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md

It's pretty slick.

Personally I'd recommend you stick it out and figure out how to make r10k
work for what you're doing. I would bet you'd be glad you did after. If you
have problems ask specific question here or IRC or Slack. There are a lot
of people using it now and there should be lots who can help.


Rich
On Fri, Jun 10, 2016 at 7:34 AM Funsaized  wrote:

> Hello,
>
> I am relatively new to puppet and am trying to develop a good workflow in
> conjunction with git/github to keep a better version control system. The
> version of puppet that I am working with and has been implemented is a bit
> dated, and using R10k and developing a puppetfile would be quite time
> consuming. I know that R10k and dynamic environments is the recommended way
> of doing things, though for now I'm not sure if its the best for my
> scenario and how everything has been previously set up. My question is is
> there a simple way to just map one git repo for each environment (dev, QA,
> production, etc). That way changes could be made in the dev environment,
> then moved over to the correct repos when the changes are confirmed in
> order? Would this be as simple as declaring each folder withing the
> /puppet/environments folder as a git repo and controlling that way?
>
> Deployment strategy
>
> -   Upload changes to Dev repo
>
> -   Deploy Dev changes to Dev master
>
> -   Test
>
> -   Merge Dev changes to QA repo
>
> -   Rinse and repeat
>
> --
> 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%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/CAPGcbtDef7BbA56udnLpB2xuQvmaoQEyYbyoX%2Bqj6WsWmTE9fQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Christopher Wood]

On Fri, Jun 10, 2016 at 05:57:13AM -0700, Funsaized wrote:
>Hello,
> 
>I am relatively new to puppet and am trying to develop a good workflow in
>conjunction with git/github to keep a better version control system. The
>version of puppet that I am working with and has been implemented is a bit
>dated, and using R10k and developing a puppetfile would be quite time
>consuming.

Yes it would be time consuming. It's worth the time. An upgrade would probably 
help you too.

>I know that R10k and dynamic environments is the recommended
>way of doing things, though for now I'm not sure if its the best for my
>scenario and how everything has been previously set up. My question is is
>there a simple way to just map one git repo for each environment (dev, QA,
>production, etc). That way changes could be made in the dev environment,
>then moved over to the correct repos when the changes are confirmed in
>order? Would this be as simple as declaring each folder withing the
>/puppet/environments folder as a git repo and controlling that way?

Been there, tried it, moved to r10k. The above is a great way to see your 
environments drift over time.

If you want each environment to be a separate git repo you can, but it sounds 
like you may as well have them all as branches in a single git repo. That way 
you can at least diff different branches easily and cherry pick single changes 
from one to the other.

>Deployment strategy
> 
>-   Upload changes to Dev repo
> 
>-   Deploy Dev changes to Dev master
> 
>-   Test
> 
>-   Merge Dev changes to QA repo
> 
>-   Rinse and repeat

What is QA for, in this scenario? Determining that you've brought up the 
correct set of changes from dev? If so, why not use git itself to prove that 
you've brought up the correct changes, as specified by git commits, to your 
mainline branch?

>--
>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 [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com?utm_medium=email_source=footer
>3. 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/20160610145454.GA23490%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Git Repo Strategy

[Funsaized]

Hello, 

I am relatively new to puppet and am trying to develop a good workflow in 
conjunction with git/github to keep a better version control system. The 
version of puppet that I am working with and has been implemented is a bit 
dated, and using R10k and developing a puppetfile would be quite time 
consuming. I know that R10k and dynamic environments is the recommended way 
of doing things, though for now I'm not sure if its the best for my 
scenario and how everything has been previously set up. My question is is 
there a simple way to just map one git repo for each environment (dev, QA, 
production, etc). That way changes could be made in the dev environment, 
then moved over to the correct repos when the changes are confirmed in 
order? Would this be as simple as declaring each folder withing the 
/puppet/environments folder as a git repo and controlling that way? 

Deployment strategy

-   Upload changes to Dev repo

-   Deploy Dev changes to Dev master

-   Test

-   Merge Dev changes to QA repo

-   Rinse and repeat

-- 
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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Git Repo Strategy

[Tom Tucker]

I just got back from PuppetConf last week and several presenters mentioned
using more than one Git repo with Puppet.  Some even recommend having a
repo per module.  For our initial Puppet deployment this seems a bit
excessive.  My plan was to have three repos for each of our environments
(Dev, QA and Production).  The contents of these repos would contain Puppet
Enterprise directory of /etc/puppetlabs/puppet.



Deployment strategy

-   Upload changes to Dev repo

-   Deploy Dev changes to Dev master

-   Test

-   Merge Dev changes to QA repo

-   Rinse and repeat





Thoughts? Any tips for a Puppet and Git newbie in regards to file
hierarchy, Git repo strategies, etc.



Thank you in advance,



Tom






Sample tree and repo of /etc/puppetlabs/puppet

# tree *

auth.conf

autosign.conf

console.conf   # File excluded this is site specific.  We will have a
unique Puppet master for each env.

environments

├── development

│   ├── hieradata

│   │   └── environmentX.yaml

│   ├── manifests

│   │   └── site.pp

│   └── modules

└── production

fileserver.conf

hieradata

├── defaults.yaml

├── master.mydomain.com.yaml

└── production.yaml

hiera.yaml [error opening dir]

manifests

├── hieradata

│   └── hostgroups.yaml

└── site.pp

modules

├── custom

puppet.conf   # File excluded this is site specific.  We will have a unique
Puppet master for each env.

puppetdb.conf   # File excluded this is site specific.  We will have a
unique Puppet master for each env.

routes.yaml

ssl # Directory excluded this is site specific

 extra lines removed





# cat hiera.yaml

---

:hierarchy:

- hieradata/fqdn/%{::fqdn}

- %{environment}/%{::osfamily}

- %{environment}/hieradata/%{::network_location}

- %{environment}/hieradata/%{::systemrole}

- hieradata/common



:backends:

- yaml



:yaml:

:datadir: /etc/puppetlabs/puppet/environments

-- 
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/CAGymF1DKrTsh%2BNO%3DQLMpP1pM80ac3MMxvbo2p0aN9q9USXLj5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Eric Shamow]

I highly recommend going with Gary Larizza’s functional puppet workflow unless 
you’ve got lots of prior experience. You can find part 1 here:

http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/

It’s a 3 part series, and there are good follow-ups on r10k and environments 
(http://garylarizza.com/blog/2014/03/26/random-r10k-workflow-ideas/) and an 
update to that post to cover directory environments 
(http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/)

Start there - there are criticisms to be had but it’s a good, tested functional 
workflow at use at a lot of orgs.

-Eric

-- 
Eric Shamow
Sent with Airmail

On September 30, 2014 at 4:17:45 PM, Tom Tucker (tktuc...@gmail.com) wrote:


I just got back from PuppetConf last week and several presenters mentioned 
using more than one Git repo with Puppet.  Some even recommend having a repo 
per module.  For our initial Puppet deployment this seems a bit excessive.  My 
plan was to have three repos for each of our environments (Dev, QA and 
Production).  The contents of these repos would contain Puppet Enterprise 
directory of /etc/puppetlabs/puppet.

 

Deployment strategy

-   Upload changes to Dev repo

-   Deploy Dev changes to Dev master

-   Test

-   Merge Dev changes to QA repo

-   Rinse and repeat

 

 

Thoughts? Any tips for a Puppet and Git newbie in regards to file hierarchy, 
Git repo strategies, etc.

 

Thank you in advance,

 

Tom







 

Sample tree and repo of /etc/puppetlabs/puppet

# tree *

auth.conf

autosign.conf

console.conf   # File excluded this is site specific.  We will have a unique 
Puppet master for each env.

environments

├── development

│   ├── hieradata

│   │   └── environmentX.yaml

│   ├── manifests

│   │   └── site.pp

│   └── modules

└── production

fileserver.conf

hieradata

├── defaults.yaml

├── master.mydomain.com.yaml

└── production.yaml

hiera.yaml [error opening dir]

manifests

├── hieradata

│   └── hostgroups.yaml

└── site.pp

modules

├── custom

puppet.conf   # File excluded this is site specific.  We will have a unique 
Puppet master for each env.

puppetdb.conf   # File excluded this is site specific.  We will have a unique 
Puppet master for each env.

routes.yaml

ssl # Directory excluded this is site specific

 extra lines removed

 

 

# cat hiera.yaml

---

:hierarchy:

    - hieradata/fqdn/%{::fqdn}

    - %{environment}/%{::osfamily}

    - %{environment}/hieradata/%{::network_location}

    - %{environment}/hieradata/%{::systemrole}

    - hieradata/common

 

:backends:

    - yaml

 

:yaml:

    :datadir: /etc/puppetlabs/puppet/environments

--
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/CAGymF1DKrTsh%2BNO%3DQLMpP1pM80ac3MMxvbo2p0aN9q9USXLj5Q%40mail.gmail.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/etPan.542b464a.238e1f29.160a6%40rassilon.local.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Garrett Honeycutt]

On 9/30/14 7:17 PM, Tom Tucker wrote:
 
 I just got back from PuppetConf last week and several presenters
 mentioned using more than one Git repo with Puppet.  Some even recommend
 having a repo per module.  For our initial Puppet deployment this seems
 a bit excessive.  My plan was to have three repos for each of our
 environments (Dev, QA and Production).  The contents of these repos
 would contain Puppet Enterprise directory of /etc/puppetlabs/puppet.
 

Hi Tom,

One big repo full of modules stops scaling pretty quickly. This path
makes it impossible to work in scenario where you have multiple parties
using the same code base. Without individually versioning modules, you
will give up the opportunity to ever make a breaking change, because you
have to appease everyone. You also quickly get into situations where you
cannot deploy the newest version of the code because it changes multiple
modules and one of those causes issues. It leads to long running forks
that will never merge, cherry picking changes, and copy/pasting code.
Avoid this at all costs and save yourself the headaches.

Here's an example[1] of how I manage a bunch of modules, each in their
own repo. You could then use this Puppetfile with tools such as
librarian-puppet-simple, librarian-puppet, and r10k. I use this repo to
track all of my 'base' or 'common' modules and then use another repo to
track site specific modules. For that repo, I highly recommend r10k.

[1] - https://github.com/ghoneycutt/puppet-modules

Best regards,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/542B5789.5080003%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Jeremy T. Bouse]

On 09/30/2014 09:23 PM, Garrett Honeycutt wrote:
 On 9/30/14 7:17 PM, Tom Tucker wrote:

 I just got back from PuppetConf last week and several presenters
 mentioned using more than one Git repo with Puppet.  Some even recommend
 having a repo per module.  For our initial Puppet deployment this seems
 a bit excessive.  My plan was to have three repos for each of our
 environments (Dev, QA and Production).  The contents of these repos
 would contain Puppet Enterprise directory of /etc/puppetlabs/puppet.

 
 Hi Tom,
 
 One big repo full of modules stops scaling pretty quickly. This path
 makes it impossible to work in scenario where you have multiple parties
 using the same code base. Without individually versioning modules, you
 will give up the opportunity to ever make a breaking change, because you
 have to appease everyone. You also quickly get into situations where you
 cannot deploy the newest version of the code because it changes multiple
 modules and one of those causes issues. It leads to long running forks
 that will never merge, cherry picking changes, and copy/pasting code.
 Avoid this at all costs and save yourself the headaches.
 
 Here's an example[1] of how I manage a bunch of modules, each in their
 own repo. You could then use this Puppetfile with tools such as
 librarian-puppet-simple, librarian-puppet, and r10k. I use this repo to
 track all of my 'base' or 'common' modules and then use another repo to
 track site specific modules. For that repo, I highly recommend r10k.
 
 [1] - https://github.com/ghoneycutt/puppet-modules
 
 Best regards,
 -g
 

I'll echo Garrett's comments that having all your modules in a single
repo severely hampers change. Like Garret I use a Puppetfile with which
I pull modules in from a a combination of the Puppet Forge and GitHub
repos. I do make mine available [1] as well and I include a README of
all the modules it includes and also note those that are pulled from the
Forge that are listed as approved or supported.

I do use r10k and Puppet 3.7.x with directory environments so each
branch of my repo is handled as a separate environment when deployed by
r10k. I have my puppet environment setup so that all I do is commit to
the GitHub repo which triggers Jenkins CI jobs that validate and push
out to the puppet master. Once validated after being pushed out I can
promote my job and it is merged from one branch to the next and runs
through the cycle again.

Regard,
Jeremy



signature.asc
Description: OpenPGP digital signature