Puppet users - Mar 2009 - Staging puppet server running on my local machine?

I''m wanting to build something along the lines of:

* I close the puppetmaster repo locally
* I start it up, puppetmasterd --confdir ~/path/to/conf
* I ssh in to the machine I want to work with, using ssh -R
8140:127.0.0.1:8140
* Then, on the remote machine, I run puppetd --test --server 127.0.0.1

Is this crazy? Is there a better way, more established way to do
something like this?

My main interest is to be able to have a testing puppetmaster that I
can update and hit while working on a specific instance, get it
working, and then merge it to our main puppet master.  Currently our
staging environment is being run on the same boxes as production, so
we don''t have the luxury of a separate cluster.

Thanks :)

Tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

That''s what VMware is for.


On Thu, Mar 26, 2009 at 3:52 PM, timcharper <timcharper@gmail.com>
wrote:
>
> I''m wanting to build something along the lines of:
>
> * I close the puppetmaster repo locally
> * I start it up, puppetmasterd --confdir ~/path/to/conf
> * I ssh in to the machine I want to work with, using ssh -R
> 8140:127.0.0.1:8140
> * Then, on the remote machine, I run puppetd --test --server 127.0.0.1
>
> Is this crazy? Is there a better way, more established way to do
> something like this?
>
> My main interest is to be able to have a testing puppetmaster that I
> can update and hit while working on a specific instance, get it
> working, and then merge it to our main puppet master.  Currently our
> staging environment is being run on the same boxes as production, so
> we don''t have the luxury of a separate cluster.
>
> Thanks :)
>
> Tim
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Yes, I recognize that would be a solution, and likely a good one, however I
believe in order for us to be able to test puppet changes before committing
and pushing them to the server, we''d all have to boot our own series of
VM''s
(in other words, we don''t have a single sysadmin).
Tim



On Thu, Mar 26, 2009 at 2:30 PM, Brian Mathis
<brian.mathis@gmail.com>wrote:
>
> That''s what VMware is for.
>
>
> On Thu, Mar 26, 2009 at 3:52 PM, timcharper <timcharper@gmail.com>
wrote:
> >
> > I''m wanting to build something along the lines of:
> >
> > * I close the puppetmaster repo locally
> > * I start it up, puppetmasterd --confdir ~/path/to/conf
> > * I ssh in to the machine I want to work with, using ssh -R
> > 8140:127.0.0.1:8140
> > * Then, on the remote machine, I run puppetd --test --server 127.0.0.1
> >
> > Is this crazy? Is there a better way, more established way to do
> > something like this?
> >
> > My main interest is to be able to have a testing puppetmaster that I
> > can update and hit while working on a specific instance, get it
> > working, and then merge it to our main puppet master.  Currently our
> > staging environment is being run on the same boxes as production, so
> > we don''t have the luxury of a separate cluster.
> >
> > Thanks :)
> >
> > Tim
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I didn''t articulate my interests.  I was trying to see if there was a
way I
could boot up a local copy of the puppetmaster, so I could edit changes and
apply them to a single server without:
A) affecting other servers, except for the one I''m targeting, until
I''m
ready to deploy
B) have a working sandbox copy that is my sandbox copy, without having to
create a sandbox for everyone who uses puppet

Now that I''m thinking about it more and have been bumping against cert
issues, I think it will be easier just to set up individual sandboxes using
the environments feature of puppet.

http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments

Thanks!  Eventually we''ll get a staging cluster built out in a series
of
VM''s, but until then I believe this will serve us well.

Tim

On Thu, Mar 26, 2009 at 2:41 PM, Tim Harper <timcharper@gmail.com> wrote:
> Yes, I recognize that would be a solution, and likely a good one, however I
> believe in order for us to be able to test puppet changes before committing
> and pushing them to the server, we''d all have to boot our own
series of VM''s
> (in other words, we don''t have a single sysadmin).
> Tim
>
>
>
>
> On Thu, Mar 26, 2009 at 2:30 PM, Brian Mathis
<brian.mathis@gmail.com>wrote:
>
>>
>> That''s what VMware is for.
>>
>>
>> On Thu, Mar 26, 2009 at 3:52 PM, timcharper
<timcharper@gmail.com> wrote:
>> >
>> > I''m wanting to build something along the lines of:
>> >
>> > * I close the puppetmaster repo locally
>> > * I start it up, puppetmasterd --confdir ~/path/to/conf
>> > * I ssh in to the machine I want to work with, using ssh -R
>> > 8140:127.0.0.1:8140
>> > * Then, on the remote machine, I run puppetd --test --server
127.0.0.1
>> >
>> > Is this crazy? Is there a better way, more established way to do
>> > something like this?
>> >
>> > My main interest is to be able to have a testing puppetmaster that
I
>> > can update and hit while working on a specific instance, get it
>> > working, and then merge it to our main puppet master.  Currently
our
>> > staging environment is being run on the same boxes as production,
so
>> > we don''t have the luxury of a separate cluster.
>> >
>> > Thanks :)
>> >
>> > Tim
>> > >
>> >
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

You don''t need "clusters" to run VMs.  They run perfectly
fine on a
local PC in 256 M of RAM (though a little more is nicer), depending on
the guest OS of course.  For sysadmins, VMs are the equivalent of CVS
and local build tools that developers use.

Anyway, glad you found what you needed.


On Thu, Mar 26, 2009 at 4:50 PM, Tim Harper <timcharper@gmail.com>
wrote:
> I didn''t articulate my interests.  I was trying to see if there
was a way I
> could boot up a local copy of the puppetmaster, so I could edit changes and
> apply them to a single server without:
> A) affecting other servers, except for the one I''m targeting,
until I''m
> ready to deploy
> B) have a working sandbox copy that is my sandbox copy, without having to
> create a sandbox for everyone who uses puppet
> Now that I''m thinking about it more and have been bumping against
cert
> issues, I think it will be easier just to set up individual sandboxes using
> the environments feature of puppet.
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
> Thanks!  Eventually we''ll get a staging cluster built out in a
series of
> VM''s, but until then I believe this will serve us well.
> Tim
>
> On Thu, Mar 26, 2009 at 2:41 PM, Tim Harper <timcharper@gmail.com>
wrote:
>>
>> Yes, I recognize that would be a solution, and likely a good one,
however
>> I believe in order for us to be able to test puppet changes before
>> committing and pushing them to the server, we''d all have to
boot our own
>> series of VM''s (in other words, we don''t have a
single sysadmin).
>> Tim
>>
>>
>>
>> On Thu, Mar 26, 2009 at 2:30 PM, Brian Mathis
<brian.mathis@gmail.com>
>> wrote:
>>>
>>> That''s what VMware is for.
>>>
>>>
>>> On Thu, Mar 26, 2009 at 3:52 PM, timcharper
<timcharper@gmail.com> wrote:
>>> >
>>> > I''m wanting to build something along the lines of:
>>> >
>>> > * I close the puppetmaster repo locally
>>> > * I start it up, puppetmasterd --confdir ~/path/to/conf
>>> > * I ssh in to the machine I want to work with, using ssh -R
>>> > 8140:127.0.0.1:8140
>>> > * Then, on the remote machine, I run puppetd --test --server
127.0.0.1
>>> >
>>> > Is this crazy? Is there a better way, more established way to
do
>>> > something like this?
>>> >
>>> > My main interest is to be able to have a testing puppetmaster
that I
>>> > can update and hit while working on a specific instance, get
it
>>> > working, and then merge it to our main puppet master.
 Currently our
>>> > staging environment is being run on the same boxes as
production, so
>>> > we don''t have the luxury of a separate cluster.
>>> >
>>> > Thanks :)
>>> >
>>> > Tim
>>> > >
>>> >
>>>
>>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

There''s a ''gepetto'' github gem that I''ve
been meaning to try out - that
solves a number of these problems.

Obvious improvements would be making it support something other than qemu.

--elijah


On Thu, Mar 26, 2009 at 4:50 PM, Tim Harper <timcharper@gmail.com> wrote:
> I didn''t articulate my interests.  I was trying to see if there
was a way I
> could boot up a local copy of the puppetmaster, so I could edit changes and
> apply them to a single server without:
> A) affecting other servers, except for the one I''m targeting,
until I''m
> ready to deploy
> B) have a working sandbox copy that is my sandbox copy, without having to
> create a sandbox for everyone who uses puppet
>
> Now that I''m thinking about it more and have been bumping against
cert
> issues, I think it will be easier just to set up individual sandboxes using
> the environments feature of puppet.
>
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> Thanks!  Eventually we''ll get a staging cluster built out in a
series of
> VM''s, but until then I believe this will serve us well.
>
> Tim
>
>
> On Thu, Mar 26, 2009 at 2:41 PM, Tim Harper <timcharper@gmail.com>
wrote:
>
>> Yes, I recognize that would be a solution, and likely a good one,
however
>> I believe in order for us to be able to test puppet changes before
>> committing and pushing them to the server, we''d all have to
boot our own
>> series of VM''s (in other words, we don''t have a
single sysadmin).
>> Tim
>>
>>
>>
>>
>> On Thu, Mar 26, 2009 at 2:30 PM, Brian Mathis
<brian.mathis@gmail.com>wrote:
>>
>>>
>>> That''s what VMware is for.
>>>
>>>
>>> On Thu, Mar 26, 2009 at 3:52 PM, timcharper
<timcharper@gmail.com>
>>> wrote:
>>> >
>>> > I''m wanting to build something along the lines of:
>>> >
>>> > * I close the puppetmaster repo locally
>>> > * I start it up, puppetmasterd --confdir ~/path/to/conf
>>> > * I ssh in to the machine I want to work with, using ssh -R
>>> > 8140:127.0.0.1:8140
>>> > * Then, on the remote machine, I run puppetd --test --server
127.0.0.1
>>> >
>>> > Is this crazy? Is there a better way, more established way to
do
>>> > something like this?
>>> >
>>> > My main interest is to be able to have a testing puppetmaster
that I
>>> > can update and hit while working on a specific instance, get
it
>>> > working, and then merge it to our main puppet master. 
Currently our
>>> > staging environment is being run on the same boxes as
production, so
>>> > we don''t have the luxury of a separate cluster.
>>> >
>>> > Thanks :)
>>> >
>>> > Tim
>>> > >
>>> >
>>>
>>>
>>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mar 26, 2009, at 2:52 PM, timcharper wrote:
>
> I''m wanting to build something along the lines of:
>
> * I close the puppetmaster repo locally
> * I start it up, puppetmasterd --confdir ~/path/to/conf
> * I ssh in to the machine I want to work with, using ssh -R
> 8140:127.0.0.1:8140
> * Then, on the remote machine, I run puppetd --test --server 127.0.0.1
>
> Is this crazy? Is there a better way, more established way to do
> something like this?
>
> My main interest is to be able to have a testing puppetmaster that I
> can update and hit while working on a specific instance, get it
> working, and then merge it to our main puppet master.  Currently our
> staging environment is being run on the same boxes as production, so
> we don''t have the luxury of a separate cluster.

This should be very straightforward, and I do it constantly.

Of course, if you''re just testing, you can almost assuredly get  
exactly the same behaviour by just running ''puppet'' against
your
site.pp and pointing it at your conf file - there''s usually no need  
for the client/server.

-- 
Morgan''s Second Law:
     To a first approximation all appointments are canceled.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---