Puppet users - Mar 2008 - Questions of best practice for someone new to puppet

I am looking at replacing our Bladelogic setup with puppet and I have
a couple of questions.

Is it best to start  with the latest and greatest 0.24.4 or should I
use the stable version 0.23.2?

How do people test config changes that puppet is managing.

A bit of background.
Currently we have a number of webservers which all have the same
configs.  After we have tested any changes that we want to make in a
test environment we push the changes out to one server and then see if
anything has broken then we either roll out the rest or roll back.

Is it possible to do this with puppet? If so how would I do this?

What do people think the best way is to manage a fairly large number
of nodes is.  I am loking at managing around 500 or so.  We use ldap
at work but do not currently use it for holding host infomation.

Thanks for the help
--~--~---------~--~----~------------~-------~--~----~
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 31, 2008, at 9:47 AM, Aaron wrote:
>
> I am looking at replacing our Bladelogic setup with puppet and I have
> a couple of questions.
Always something I like to hear. :)
>
> Is it best to start  with the latest and greatest 0.24.4 or should I
> use the stable version 0.23.2?
IMO, you should use 0.24.4.  It has (as you can tell by the last  
number) many bugfixes in it, and the 0.23.2 Debian packages (no idea  
if you''re using Debian) have some maintainer patches that cause  
significant breakage.  (That maintainer is no longer responsible for  
the package, and the current packages are great.)

Once 0.24.4 has been out long enough (a few weeks at least), I expect  
we''ll bump it to the stable release.
>
> How do people test config changes that puppet is managing.
>
> A bit of background.
> Currently we have a number of webservers which all have the same
> configs.  After we have tested any changes that we want to make in a
> test environment we push the changes out to one server and then see if
> anything has broken then we either roll out the rest or roll back.
>
> Is it possible to do this with puppet? If so how would I do this?
This is still an essentially manual process with Puppet (that is, the  
change control is manual -- Puppet still does the work).

Obviously this is where I want to move in the future, but Puppet  
doesn''t currently have this kind of client/server state knowledge, nor
the rolling upgrade that you''re interested in.
>
> What do people think the best way is to manage a fairly large number
> of nodes is.  I am loking at managing around 500 or so.  We use ldap
> at work but do not currently use it for holding host infomation.
A lot depends on your environment.  For simple node heirarchies, the  
current in-language node constructs work fine.  I hope to provide a  
builtin replacement for them in the near future -- something as simple  
as they are but with a hierarchy model that better suits nodes,  
instead of the current one only suited for classes.

If you''ve already got some kind of inventory application, which many  
people have, then it''s straightforward to write an app that sends that
info to Puppet via its external nodes interface.

If you don''t have any existing inventory app, then you get to decide  
whether you want such a thing and how to go about it.  This is always  
a bit more work, but the rewards are potentially greater.

-- 
Brand''s Asymmetry:
     The past can only be known, not changed. The future can only be
     changed, not known.
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---

Hi
> How do people test config changes that puppet is managing.
maybe you''re interested in a setup like that:
http://reductivelabs.com/trac/puppet/wiki/CommonModules

This let you test it on one (by using the environment testing) and the
push it to all the other by commiting it to production.

greets pete

--~--~---------~--~----~------------~-------~--~----~
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 31 Mar, 16:52, Luke Kanies <l...@madstop.com>
wrote:
> On Mar 31, 2008, at 9:47 AM, Aaron wrote:
>
>
>
> > I am looking at replacing our Bladelogic setup with puppet and I have
> > a couple of questions.
>
> Always something I like to hear. :)
>
>
>
> > Is it best to start  with the latest and greatest 0.24.4 or should I
> > use the stable version 0.23.2?
>
> IMO, you should use 0.24.4.  It has (as you can tell by the last
> number) many bugfixes in it, and the 0.23.2 Debian packages (no idea
> if you''re using Debian) have some maintainer patches that cause
> significant breakage.  (That maintainer is no longer responsible for
> the package, and the current packages are great.)
>
> Once 0.24.4 has been out long enough (a few weeks at least), I expect
> we''ll bump it to the stable release.
thnx
>
>
>
> > How do people test config changes that puppet is managing.
>
> > A bit of background.
> > Currently we have a number of webservers which all have the same
> > configs.  After we have tested any changes that we want to make in a
> > test environment we push the changes out to one server and then see if
> > anything has broken then we either roll out the rest or roll back.
>
> > Is it possible to do this with puppet? If so how would I do this?
>
> This is still an essentially manual process with Puppet (that is, the
> change control is manual -- Puppet still does the work).
>
> Obviously this is where I want to move in the future, but Puppet
> doesn''t currently have this kind of client/server state knowledge,
nor
> the rolling upgrade that you''re interested in.
>
Does this mean it is possible ''freeze'' a class or module on
all the
nodes
and then force the new changes on a single host?  I was wondering if
this
is what the noop was for?
>
>
> > What do people think the best way is to manage a fairly large number
> > of nodes is.  I am loking at managing around 500 or so.  We use ldap
> > at work but do not currently use it for holding host infomation.
>
> A lot depends on your environment.  For simple node heirarchies, the
> current in-language node constructs work fine.  I hope to provide a
> builtin replacement for them in the near future -- something as simple
> as they are but with a hierarchy model that better suits nodes,
> instead of the current one only suited for classes.
>
> If you''ve already got some kind of inventory application, which
many
> people have, then it''s straightforward to write an app that sends
that
> info to Puppet via its external nodes interface.
I shall have a look at the external nodes.
>
> If you don''t have any existing inventory app, then you get to
decide
> whether you want such a thing and how to go about it.  This is always
> a bit more work, but the rewards are potentially greater.
>
> --
> Brand''s Asymmetry:
>      The past can only be known, not changed. The future can only be
>      changed, not known.
> ---------------------------------------------------------------------
> 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
-~----------~----~----~----~------~----~------~--~---

On 31 Mar, 17:41, Peter Meier <peter.me...@immerda.ch>
wrote:
> Hi
>
> > How do people test config changes that puppet is managing.
>
> maybe you''re interested in a setup like
that:http://reductivelabs.com/trac/puppet/wiki/CommonModules
>
> This let you test it on one (by using the environment testing) and the
> push it to all the other by commiting it to production.
>
> greets pete
This sounds interesting I''ll look into this
thnx

--~--~---------~--~----~------------~-------~--~----~
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 31, 2008, at 1:58 PM, Aaron wrote:
>>> Currently we have a number of webservers which all have the same
>>> configs.  After we have tested any changes that we want to make in
a
>>> test environment we push the changes out to one server and then  
>>> see if
>>> anything has broken then we either roll out the rest or roll back.
>>
>>> Is it possible to do this with puppet? If so how would I do this?
>>
>> This is still an essentially manual process with Puppet (that is, the
>> change control is manual -- Puppet still does the work).
>>
>> Obviously this is where I want to move in the future, but Puppet
>> doesn''t currently have this kind of client/server state
knowledge,
>> nor
>> the rolling upgrade that you''re interested in.
>>
>
> Does this mean it is possible ''freeze'' a class or module
on all the
> nodes
> and then force the new changes on a single host?  I was wondering if
> this
> is what the noop was for?

No, it''s not really possible.

I''m fond of saying in my presentations on Puppet that Puppet fixes  
your initial biggest problem -- that of getting the work done on your  
hosts -- but that just moves your second biggest problem (managing  
changes) into being your biggest problem.

I''m not trying to downplay the difficulty or importance of this,
it''s
just that I haven''t been able to get it done yet.

0.25, which might yet be out before mid-year, will at least enable  
this kind of functionality, although it almost definitely won''t ship  
with it directly (unless someone wants to fund the work).  At best, I  
could provide a separation between recompiling and applying a  
configuration, which would kind of get you there, but it''s still not  
the whole thing.

If you want this behaviour and are in a position to either help or  
fund it, you''re in a good position to define what it would look like.

-- 
I happen to feel that the degree of a person''s intelligence is directly
reflected by the number of conflicting attitudes she can bring to bear
on the same topic. -- Lisa Alther
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 31 March 2008, Luke Kanies wrote:
> On Mar 31, 2008, at 1:58 PM, Aaron wrote:
> >>> Currently we have a number of webservers which all have the
same
> >>> configs.  After we have tested any changes that we want to
make in a
> >>> test environment we push the changes out to one server and
then
> >>> see if
> >>> anything has broken then we either roll out the rest or roll
back.
> >>>
> >>> Is it possible to do this with puppet? If so how would I do
this?
> >>
> >> This is still an essentially manual process with Puppet (that is,
the
> >> change control is manual -- Puppet still does the work).
> >>
> >> Obviously this is where I want to move in the future, but Puppet
> >> doesn''t currently have this kind of client/server state
knowledge,
> >> nor
> >> the rolling upgrade that you''re interested in.
> >
> > Does this mean it is possible ''freeze'' a class or
module on all the
> > nodes
> > and then force the new changes on a single host?  I was wondering if
> > this
> > is what the noop was for?
>
> No, it''s not really possible.
>
> I''m fond of saying in my presentations on Puppet that Puppet fixes
> your initial biggest problem -- that of getting the work done on your
> hosts -- but that just moves your second biggest problem (managing
> changes) into being your biggest problem.
> I''m not trying to downplay the difficulty or importance of this,
it''s
> just that I haven''t been able to get it done yet.
Isn''t this what environments were done for? I can imagine doing a kind 
of "rolling update" e.g. by changing clients one by one from one
environment
to the next; e.g. enconding date/version, like from "prod-2008-01.23" 
to "prod-2008-02.17".


Regards, DavidS
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFH86xS/Pp1N6Uzh0URAgcCAJibWVU+zLiH76e0SRw+CZCFd+lJAJwJGCn+
yINIP5v0lnupDjRhbzdhQQ==Op6q
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> Isn''t this what environments were done for? I can imagine doing a
kind
> of "rolling update" e.g. by changing clients one by one from one
environment
> to the next; e.g. enconding date/version, like from
"prod-2008-01.23"
> to "prod-2008-02.17".
>
I am guessing so and I am now playing with environments and have got
it working.

I am starting to see the end of the tunnel for the pain which is
blade :-)

Aaron
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Aaron-
   If you have not yet picked up James Turnbull''s book, I suggest you
do so. I set up puppet the first time without but after about 15
minnutes in to the book, I have foudn a lto of really usefull info
that is not really anywhere on the puppet site.Or if it is, it is so
buried a beginner does not know where to look for it.

Evan
( Busy rebuilding my puppet)

On Wed, Apr 2, 2008 at 11:59 AM, Aaron <busukajw@gmail.com>
wrote:
>
>
>  > Isn''t this what environments were done for? I can imagine
doing a kind
>  > of "rolling update" e.g. by changing clients one by one
from one environment
>  > to the next; e.g. enconding date/version, like from
"prod-2008-01.23"
>  > to "prod-2008-02.17".
>  >
>
>  I am guessing so and I am now playing with environments and have got
>  it working.
>
>  I am starting to see the end of the tunnel for the pain which is
>  blade :-)
>
>  Aaron
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---