Puppet users - Aug 2013 - Possible for each user to have their own testing environment?

Hello all =)

What I would like is a way so multiple people can make changes to all files 
in /etc/puppet/, but only after they have tested their changes then they 
"git push" so /etc/puppet is updated. The git repo is in /etc/puppet.
When
I read about environments [1] I get the impression that is only for module 
development, is that correct?

Ideally what I would like is each user to have their private environment 
where they can "git pull" to. E.g. 

ssh sandra@puppet
cd /home/sandra/puppet
git pull
# edit files
exit

ssh root@node
puppet agent --environment sandra

exit


ssh sandra@puppet
cd /home/sandra/puppet
git push

Can something like this be done? And if so, what would my
/etc/puppet/puppet.conf look like?


Lots of love,

Sandra =)


[1]: http://docs.puppetlabs.com/guides/environment.html

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Environments is definitely the way to handle this.  Typically you would set
up environments under /etc/puppet/environments/sandra and have all your
code in there.

Is the issue that you prefer that developers do not have code in
/etc/puppet/environments?  If you look at the puppet.conf in the link you
provided, you can see that you can setup the path used for any environment,
so you can put the files anywhere you want.


❧ Brian Mathis


On Thu, Aug 15, 2013 at 10:14 AM, Sandra Schlichting <
littlesandra88@gmail.com> wrote:
> Hello all =)
>
> What I would like is a way so multiple people can make changes to all
> files in /etc/puppet/, but only after they have tested their changes then
> they "git push" so /etc/puppet is updated. The git repo is in
/etc/puppet.
> When I read about environments [1] I get the impression that is only for
> module development, is that correct?
>
> Ideally what I would like is each user to have their private environment
> where they can "git pull" to. E.g.
>
> ssh sandra@puppet
> cd /home/sandra/puppet
> git pull
> # edit files
> exit
>
> ssh root@node
> puppet agent --environment sandra
>
> exit
>
>
> ssh sandra@puppet
> cd /home/sandra/puppet
> git push
>
> Can something like this be done? And if so, what would my
/etc/puppet/puppet.conf look like?
>
>
> Lots of love,
>
> Sandra =)
>
>
> [1]: http://docs.puppetlabs.com/guides/environment.html
>
> --
> 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+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On 16 August 2013 00:14, Sandra Schlichting
<littlesandra88@gmail.com>wrote:
> Hello all =)
>
> What I would like is a way so multiple people can make changes to all
> files in /etc/puppet/, but only after they have tested their changes then
> they "git push" so /etc/puppet is updated. The git repo is in
/etc/puppet.
> When I read about environments [1] I get the impression that is only for
> module development, is that correct?
>
> Ideally what I would like is each user to have their private environment
> where they can "git pull" to. E.g.
>
> Can something like this be done? And if so, what would my
> /etc/puppet/puppet.conf look like?
>
This is exactly what we do - each admin has their own environment. We use
SVN, so substitute where required, but essentially we force a particular
directory structure for every admin and reflect that in the
puppetmaster.conf of our lab server. NB the SVN work spaces must be on the
same server as the lab puppet server for this to work

# Replicate this, and change "username" as appropriate (one per line)
#[Lusername]
#    modulepath = /u1/username/svn-workspace/puppet/Lusername/modules
#    manifest /u1/username/svn-workspace/puppet/Lusername/manifests/site.pp
#    manifestdir = /u1/username/svn-workspace/puppet/Lusername/manifests

Because we have different yum/pkg repos per environment, that capital L for
the environment allows us to do some generic regexp matching to override to
a single "lab" repo and not one per admin

All changes are a feature
branch<http://nvie.com/posts/a-successful-git-branching-model/>,
and we wrap the creation of a JIRA ticket, new feature branch name based on
JIRA ticket number (UX-0000) and sym link
/u1/username/svn-workspace/puppet/Lusername to
/u1/username/svn-workspace/puppet/branches/UX-0000 in a script

We then set the environment of whatever development VM/server we need to
develop/test the code - including full rebuilds and "it just works".
We
have another script which checks for a valid peer review (reviewboard) then
merges the changes back into develop/trunk, and updates the JIRA ticket

The only gotcha is if you have multiple feature branches at any time and
managing the sym link

John

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Git branching and environments is exactly what we did to solve this 
problem. We are actually using gitolite which allows us to lock down who 
can push to certain branches. So anyone can create their own branch, push 
that up (which creates the proper directories through git hooks) and test 
with --environment [branch_name] and then when they know it works great, 
request a merge into our permanent environments like production and 
testing. Once the new code is merged into its final home, the temporary 
branch is deleted. 

The hard part is the git hooks. We actually have a script that emulates the 
"Github" WebHook URL functionality and a hook that "catches"
that POST and
does all the magic. I included the web pages that helped me get our setup 
working how we wanted it to.

https://github.com/metajack/notify-webhook
https://puppetlabs.com/blog/git-workflow-and-puppet-environments/

On Thursday, August 15, 2013 8:14:59 AM UTC-6, Sandra Schlichting
wrote:
>
> Hello all =)
>
> What I would like is a way so multiple people can make changes to all 
> files in /etc/puppet/, but only after they have tested their changes then 
> they "git push" so /etc/puppet is updated. The git repo is in
/etc/puppet.
> When I read about environments [1] I get the impression that is only for 
> module development, is that correct?
>
> Ideally what I would like is each user to have their private environment 
> where they can "git pull" to. E.g. 
>
> ssh sandra@puppet
> cd /home/sandra/puppet
> git pull
> # edit files
> exit
>
> ssh root@node
> puppet agent --environment sandra
>
> exit
>
>
> ssh sandra@puppet
> cd /home/sandra/puppet
> git push
>
> Can something like this be done? And if so, what would my
/etc/puppet/puppet.conf look like?
>
>
> Lots of love,
>
> Sandra =)
>
>
> [1]: http://docs.puppetlabs.com/guides/environment.html
>
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Dear Brian and John,

Thanks a lot for your replies. I was under the impression that site.pp had 
to be in the environment, which I now see it doesn''t have to. =)

What I don''t quite understand is though is the following:

There are four forbidden environment names:
>    
>    - main
>
>
>    - master
>
>
>    - agent
>
>
>    - user
>
> These names are already taken by the primary config
blocks<http://docs.puppetlabs.com/guides/configuring.html#config-blocks>.
> If you are using Git branches for your environment names, this may mean 
> you’ll need to rename the master branch to something like production or 
> stable.

How can a git branch name (master) conflict with content in the puppet.conf 
file?

Hugs,
Sandra =)






On Friday, 16 August 2013 01:14:44 UTC+2, John Warburton
wrote:
>
> On 16 August 2013 00:14, Sandra Schlichting
<littles...@gmail.com<javascript:>
> > wrote:
>
>> Hello all =)
>>
>> What I would like is a way so multiple people can make changes to all 
>> files in /etc/puppet/, but only after they have tested their changes
then
>> they "git push" so /etc/puppet is updated. The git repo is in
/etc/puppet.
>> When I read about environments [1] I get the impression that is only
for
>> module development, is that correct?
>>
>> Ideally what I would like is each user to have their private
environment
>> where they can "git pull" to. E.g. 
>>
>  
>
>> Can something like this be done? And if so, what would my 
>> /etc/puppet/puppet.conf look like?
>>
>  
> This is exactly what we do - each admin has their own environment. We use 
> SVN, so substitute where required, but essentially we force a particular 
> directory structure for every admin and reflect that in the 
> puppetmaster.conf of our lab server. NB the SVN work spaces must be on the 
> same server as the lab puppet server for this to work
>
> # Replicate this, and change "username" as appropriate (one per
line)
> #[Lusername]
> #    modulepath = /u1/username/svn-workspace/puppet/Lusername/modules
> #    manifest = 
> /u1/username/svn-workspace/puppet/Lusername/manifests/site.pp
> #    manifestdir = /u1/username/svn-workspace/puppet/Lusername/manifests
>
> Because we have different yum/pkg repos per environment, that capital L 
> for the environment allows us to do some generic regexp matching to 
> override to a single "lab" repo and not one per admin
>
> All changes are a feature
branch<http://nvie.com/posts/a-successful-git-branching-model/>,
> and we wrap the creation of a JIRA ticket, new feature branch name based on
> JIRA ticket number (UX-0000) and sym link 
> /u1/username/svn-workspace/puppet/Lusername to 
> /u1/username/svn-workspace/puppet/branches/UX-0000 in a script
>
> We then set the environment of whatever development VM/server we need to 
> develop/test the code - including full rebuilds and "it just
works". We
> have another script which checks for a valid peer review (reviewboard) then
> merges the changes back into develop/trunk, and updates the JIRA ticket
>
> The only gotcha is if you have multiple feature branches at any time and 
> managing the sym link
>
> John
>
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On 2013-08-19 16:23, Sandra Schlichting wrote:
> Dear Brian and John,
>
> Thanks a lot for your replies. I was under the impression that site.pp
> had to be in the environment, which I now see it doesn''t have to.
=)
>
> What I don''t quite understand is though is the following:
>
>     There are four forbidden environment names:
>
>       * |main|
>
>       * |master|
>
>       * |agent|
>
>       * |user|
>
>     These names are already taken by the primary config blocks
>    
<http://docs.puppetlabs.com/guides/configuring.html#config-blocks>.
>     If you are using Git branches for your environment names, this may
>     mean you’ll need to rename the master branch to something like
>     |production| or |stable|.
>
>
> How can a git branch name (master) conflict with content in the
> puppet.conf file?
When using puppet agent --environment=master, the [master] section 
containing configuration directives (e.g. database connection for 
puppetdb) will be interpreted by the puppet agent, with less than 
stellar results.


Regards, David

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Mon, Aug 19, 2013 at 10:23 AM, Sandra Schlichting <
littlesandra88@gmail.com> wrote:
> Dear Brian and John,
>
> Thanks a lot for your replies. I was under the impression that site.pp had
> to be in the environment, which I now see it doesn''t have to. =)
>
> What I don''t quite understand is though is the following:
>
> There are four forbidden environment names:
>>
>>    - main
>>
>>
>>    - master
>>
>>
>>    - agent
>>
>>
>>    - user
>>
>> These names are already taken by the primary config
blocks<http://docs.puppetlabs.com/guides/configuring.html#config-blocks>.
>> If you are using Git branches for your environment names, this may mean
>> you’ll need to rename the master branch to something like production or
>> stable.
>
>
> How can a git branch name (master) conflict with content in the
> puppet.conf file?
>
> Hugs,
> Sandra =)
>

The environment name is just a directory within the
/etc/puppet/environments directory, nothing more.  If you use a git branch
named ''master'', you will just have to check it out into an
environment
directory with a different name, such as ''production'',
''main'', etc...  It
doesn''t matter what you want to call the environment directory, as long
as
it''s not one of those 4 you mentioned above, and git does not care what
the
name of the directory the files are checked out into.  Puppet is not doing
any sort of checking with git to see what the branch name is.


❧ Brian Mathis

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, 19 August 2013 15:48:38 UTC+2, myeazel wrote:
>
> Git branching and environments is exactly what we did to solve this 
> problem. We are actually using gitolite which allows us to lock down who 
> can push to certain branches. So anyone can create their own branch, push 
> that up (which creates the proper directories through git hooks) and test 
> with --environment [branch_name] and then when they know it works great, 
> request a merge into our permanent environments like production and 
> testing. Once the new code is merged into its final home, the temporary 
> branch is deleted. 
>
> The hard part is the git hooks. We actually have a script that emulates 
> the "Github" WebHook URL functionality and a hook that
"catches" that POST
> and does all the magic. I included the web pages that helped me get our 
> setup working how we wanted it to.
>
> https://github.com/metajack/notify-webhook
> https://puppetlabs.com/blog/git-workflow-and-puppet-environments/
>
>
Thanks a really cool script! 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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

> > How can a git branch name (master) conflict with content in the 
> > puppet.conf file? 
>
> When using puppet agent --environment=master, the [master] section 
> containing configuration directives (e.g. database connection for 
> puppetdb) will be interpreted by the puppet agent, with less than 
> stellar results. 
>
>
That makes a lot of sense, why "master" is not allowed as an
environment
name.

 

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

> The environment name is just a directory within the 
> /etc/puppet/environments directory, nothing more.  If you use a git branch 
> named ''master'', you will just have to check it out into
an environment
> directory with a different name, such as ''production'',
''main'', etc...  It
> doesn''t matter what you want to call the environment directory, as
long as
> it''s not one of those 4 you mentioned above, and git does not care
what the
> name of the directory the files are checked out into.  Puppet is not doing 
> any sort of checking with git to see what the branch name is.
>
>
Than I am more relaxed. =) Since PuppetLabs mentioned git, I was under the 
impression that I had to rename the native "master" branch in git,
which it
creates as default.

This is what my plan is, which I hope is not a problem?

cd /etc/puppet
git init
git add fileserver manifests/classes modules nodes
git commit -m "init commit from puppet2"
git branch

# outputs

* master

and then puppet.conf would become

[main]
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    ssldir = $vardir/ssl

[agent]
    classfile = $vardir/classes.txt
    localconfig = $vardir/localconfig

[sandra]
    modulepath = $confdir/environments/sandra/modules
    manifestdir = $confdir/environments/sandra/manifests
    manifest = $confdir/environments/sandra/site.pp

where site.pp contains

filebucket {''main'':
        server => "puppet.example.com",
        path   => false,
}
File { backup => main }
Exec { path => 
"/usr/bin:/usr/sbin/:/bin:/sbin:/usr/local/bin:/usr/local/sbin" }
import ''classes/*.pp''
import ''../nodes/*.pp''

To use it, I would

cd /etc/puppet/environments
git clone /etc/puppet sandra
cd sandra

This would not conflict, right?

I don''t have a [master] block in puppet.conf. Is that needed in this
case?






-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.