Questions of best practice for someone new to puppet
Aaron
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
Luke Kanies
>
> 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
Peter Meier
> 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
Aaron
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.
>
>
> > 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.
>
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.
Aaron
thnx
Luke Kanies
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
David Schmitt
Hash: SHA1
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-----
Aaron
> 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".
>
it working.
I am starting to see the end of the tunnel for the pain which is
blade :-)
Aaron
Evan Hisey
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)