Re: [Puppet Users] Making the new users experience easier
On Tue, Feb 2, 2010 at 5:08 PM, Michael DeHaan mich...@reductivelabs.com wrote: With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? #1 has to be variable scope and the inability to redefine variables. That and the knock on impact on things like inheritance, and the need for storeconfigs to 'know about' the variables of another node. #2 is the difficulty to test manifests reliably (the reliance on Facts makes it tricky to even syntax check recipes without actually running it on a node). Makes #1 more of an issue. I keep getting bitten by interactions between modules, so it needs to be some sort of integration test. #3 is a best practice guide - e.g. is it best to have a separate class heirarchy per OS / role, or fill your modules with case statements? There are solutions/mitigations to all of these issues, the trouble is there seem to be several solutions to all these issues :) Oh, and while I'm posting, congratulations on the new job, Michael :) of these :) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Declarative style and processes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This hits close to home with something that I would love to see added to
the puppetmaster but haven't quite figured out how to describe until
recently.
I recently realized that, for a given environment, what you actually
have is a massive parallel program running across various nodes.
Therefore, what I would like in the puppetmaster is a set of
stored-state named semaphores.
They would work as follows:
Semaphore: DB=0 on the puppetmaster
node web_server {
if semaphore('semaphore_db') 0 {
include foo
include bar
}
}
node db_server {
include db
}
class db {
service { some_db:
ensure = 'running',
require = Exec['set_me_up']
}
exec { 'set_me_up':
command = 'do stuff',
notify = semaphore('semaphore_db', '=', '1')
}
}
So, what this would do, is to set the semaphore $semaphore_db to 1 only
if the exec properly executes (which means that the DB got set up
correctly) and then would only set it to 1 if it was not already = 1 so
that multi-state processes can be handled.
Then, once the semaphore has been set, web_server would include what it
needed to properly function.
Note that this is not a locking process, the normal run of puppet would
ensue and the state change would only be noticed on the next run.
This does lag things out over a few runs of puppet, but also (I think)
keeps the entire thing running the 'puppet way' by essentially setting a
cross-system state fact.
I figured that the semaphore call would be an TLS REST call back to the
master, or a separate lookup process if you wanted to offload the work
to a different system.
Thanks,
Trevor
On 02/04/2010 03:42 PM, Michael DeHaan wrote:
On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger john.bollin...@stjude.org wrote:
On Feb 3, 3:08 pm, Michael DeHaan mich...@reductivelabs.com wrote:
Actually I think it can be done by leveraging an improved storeconfigs and
the existing language.
I was wondering whether storeconfigs would come up. The problem I see
with that is storeconfigs, as I understand them, record the managed
resource states each host *should* have, not necessarily those each
one *does* have. What happens to my multinode deployment if at some
point in the middle, Puppet fails to apply a necessary resource state?
If Puppet fails applying a state, it should record the current state,
not the once and future state.
I'll dig into the schema of what it does now, but don't limit your
thinking based on what storeconfigs currently does or is,
think about what it can be.
Absolutely so, and that connects back to your earlier comments about
message buses. Messaging is the lifeblood of any kind of
orchestration technology, but there are a variety of message exchange
patterns, message implementations, and messaging options, many
combinations of which are viable. Some could reasonably be
characterized as push, but many others couldn't.
This is an software architecture statement, and architecture is
independent of execution and concepts.
Long term, I expect to see messaging will happen and can then play a
much wider role mainly for offline delivery implications
and routing. Though much can be hinged on present workings, whether
RESTful or RPCy (which, aren't all that different regardless).
However, first, small steps.
Any way around, there is a class of messages needed for this that
Puppet does not currently have: messages from clients advertising the
individual or collective state of their managed resources. The
absolute simplest form would be a reply to the Puppetmaster indicating
whether a catalog was successfully applied, but finer-grained state
messages would be much more flexible. These would address the problem
of discrepancy between supposed and actual state.
Eventing and reporting, and an evolved storeconfigs concept are
something we're looking at, for sure.
Stay tuned, and of course, if you have time, patches are very much welcome.
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvaug...@onyxpoint.com
phone: 410-541-ONYX (6699)
- -- This account not approved for unencrypted sensitive information --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktr9CYACgkQyWMIJmxwHpR1kwCgvsOCN3x30q/INfSn2yQ0DTSR
aOwAnjztorRfAVsdCGk9UdyCxDZy3Ok6
=9cF1
-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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Plugins in modules with environments and the puppetmaster libdir
Nigel Kersten wrote: So facter plugins are kind of different, as they're not actually required to be in the puppetmaster libdir. Say this was a type/provider, and you wanted to add a new parameter, but only roll it out to your testing environments. Functions also have this limitation, by the way. What do you do then? If the version in the puppetmaster libdir doesn't accept that parameter, the manifest compilation will fail for clients who *are* getting a version of the plugin that supports that parameter. You lose... Well, there are a couple of things you can do to work around this limitation. For one thing, you could run a second puppetmaster process, perhaps on another port, or listening on another IP address, or perhaps even on another machine. Another thing you can do, is to run puppet with local manifests, instead of puppetd connecting to puppetmasterd, when developing the new version of the plugin. That's what I do. It does get a bit iffy if your manifests want to fetch files from the puppetmaster (i.e. that aren't in the modules namespace) though, or otherwise need to access files that are only available on the puppetmaster. Good news, though, is that the upcoming Rowlf version of Puppet is supposed to solve this for at least resource types. At least Luke has posted patches to the devel list that I gather will do that. But it will probably still be a problem for custom functions (I have somewhat volunteered to take a look at it, but I'm unlikely to find the time before Rowlf is supposed to be out). /Bellman -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Making the new users experience easier
Le mardi 02 février 2010 à 12:08 -0500, Michael DeHaan a écrit : Just one more email and I'll let you go for a few hours :) Hello puppeters One of the things I like to see in apps is that they are immediately intuitive and easy to use for new users. I think Puppet is really good here, but there's opportunity to make everything better. We want everyone to love Puppet from their first few minutes using it, all the way through to datacenter nirvana. With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? To join Peter : SSL. SSL is just a pain in the a**. As you said, some don't want to know about ruby webservers in detail, some don't want to know about SSL. Tell more in the beginner's guide about DNS, and the need to have a clean DNS for puppet to work fine. A place to share manifests. To me the wiki is not the right way to do this. A kind of puppet github would be nice : you push your classes into it, other people get them. A common errors list that beginners can search through to find error. The poptop project has some pages like this that ease debugging. BTW, some error messages would need to be a little user friendly My 0.02€ Nico. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Puppet Users] Making the new users experience easier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/02/10 11:06 PM, Nicolas Szalay wrote: A common errors list that beginners can search through to find error. The poptop project has some pages like this that ease debugging. BTW, some error messages would need to be a little user friendly Nico http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions See the Troubleshooting and areas below. Please feel free to add to this! Thanks James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS2wKriFa/lDkFHAyAQIlYAgAxdMGrbdU9D6pX0wFMmocwkQ9+CRYN2l3 QoLd/GK7JjdNYqwX0ON+E+loWzipgpbZNFQDtw3Y3jdej0LXdWpHaBbe7ifRCu+2 G+1PnU7amp04FDjXYsa8xJPRo4Sa/Fp0S6hFizBfPKza9dLVdbPIlbRWswjTtp/i +BuYYjO9ZUa4jw6se92UWuTVdKWG3h83hAXUqSNh3RKm+OdC1uY0mq5sUtYhgUdq QY62dUB09+eXRcb0scF8zMkt72/o21TMgtX5/xIW2tc8kDIYY9mbB0QzyNXGuJtk Zge5w0Vas2Y5GQfOZxiotQ/is6MeCClUu01cJ60HS9kXRHW8VwjznA== =zt7D -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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Making the new users experience easier
Le vendredi 05 février 2010 à 23:10 +1100, James Turnbull a écrit : http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions See the Troubleshooting and areas below. Please feel free to add to this! I did not remember this one :) I added a few lines :) Nico. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Puppet Users] defining nagios hostgroupescalations
Matthew Delves wrote: Hey All, I'm looking for a way to get puppet to define nagios hostgroupescalations. Is this possible and if so, what is the syntax? Thanks, Matt Delves You would create a define, and then inside that define have a file resource that uses a template to create a nagios .cfg file. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L'ennui est contre-révolutionnaire -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Checking the status of puppetd run
On Thu, Feb 4, 2010 at 11:39 PM, Eric Sorenson ahp...@gmail.com wrote: On Feb 4, 2010, at 9:29 PM, Dan Bode wrote: Question 2: I also noticed that sometimes I have to run it twice to get all the changes through. That might be because of errors in the manifests, but I've seen that happen also when everything should be fine. Is there a reason for this? this should never be required. Possibly you are not using the require/before/notify/subscribe metaparameters to specify the correct ordering? We not never, right? never = almost never. If you have added tools that a provider needs to enable itself (say, the 'gem' executable) , puppet won't pick it up until its next initialisation. I've also seen ldap dependencies not get picked up immediately after binding, so for instance creating user directories which auto-require that user to exist will fail until the next run. this is true The first one might be addressable with some introspection, like a metaparameter to signal puppet to re-initialise without exiting, the second one looks pretty much like a race condition that one could probably sleep() around in an exec. I hadnt considered cases where your dependencies have to sync with an external source. -=Eric -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Declarative style and processes
you can do all of this stuff already today (maybe not naively).
a lot of people use functions to query or set values on some external data,
output from the function can define which resources get evaluated etc.
another option some people use is to set facter_xxx environment variables
instead of external puppet functions.
i do agree, that at the end of the day, the 30 minutes default time is
insufficient, if you want to make a lot of changes - e.g. at the end you
must wait 30 minutes between each state change (assuming you have many
clients and a few states).
so in this case, I have a gut feeling which says - use the best tool for the
job, maybe puppet is not the right choice on such cases.
Ohad
On Fri, Feb 5, 2010 at 6:34 PM, Trevor Vaughan tvaug...@onyxpoint.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This hits close to home with something that I would love to see added to
the puppetmaster but haven't quite figured out how to describe until
recently.
I recently realized that, for a given environment, what you actually
have is a massive parallel program running across various nodes.
Therefore, what I would like in the puppetmaster is a set of
stored-state named semaphores.
They would work as follows:
Semaphore: DB=0 on the puppetmaster
node web_server {
if semaphore('semaphore_db') 0 {
include foo
include bar
}
}
node db_server {
include db
}
class db {
service { some_db:
ensure = 'running',
require = Exec['set_me_up']
}
exec { 'set_me_up':
command = 'do stuff',
notify = semaphore('semaphore_db', '=', '1')
}
}
So, what this would do, is to set the semaphore $semaphore_db to 1 only
if the exec properly executes (which means that the DB got set up
correctly) and then would only set it to 1 if it was not already = 1 so
that multi-state processes can be handled.
Then, once the semaphore has been set, web_server would include what it
needed to properly function.
Note that this is not a locking process, the normal run of puppet would
ensue and the state change would only be noticed on the next run.
This does lag things out over a few runs of puppet, but also (I think)
keeps the entire thing running the 'puppet way' by essentially setting a
cross-system state fact.
I figured that the semaphore call would be an TLS REST call back to the
master, or a separate lookup process if you wanted to offload the work
to a different system.
Thanks,
Trevor
On 02/04/2010 03:42 PM, Michael DeHaan wrote:
On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger john.bollin...@stjude.org
wrote:
On Feb 3, 3:08 pm, Michael DeHaan mich...@reductivelabs.com wrote:
Actually I think it can be done by leveraging an improved storeconfigs
and
the existing language.
I was wondering whether storeconfigs would come up. The problem I see
with that is storeconfigs, as I understand them, record the managed
resource states each host *should* have, not necessarily those each
one *does* have. What happens to my multinode deployment if at some
point in the middle, Puppet fails to apply a necessary resource state?
If Puppet fails applying a state, it should record the current state,
not the once and future state.
I'll dig into the schema of what it does now, but don't limit your
thinking based on what storeconfigs currently does or is,
think about what it can be.
Absolutely so, and that connects back to your earlier comments about
message buses. Messaging is the lifeblood of any kind of
orchestration technology, but there are a variety of message exchange
patterns, message implementations, and messaging options, many
combinations of which are viable. Some could reasonably be
characterized as push, but many others couldn't.
This is an software architecture statement, and architecture is
independent of execution and concepts.
Long term, I expect to see messaging will happen and can then play a
much wider role mainly for offline delivery implications
and routing. Though much can be hinged on present workings, whether
RESTful or RPCy (which, aren't all that different regardless).
However, first, small steps.
Any way around, there is a class of messages needed for this that
Puppet does not currently have: messages from clients advertising the
individual or collective state of their managed resources. The
absolute simplest form would be a reply to the Puppetmaster indicating
whether a catalog was successfully applied, but finer-grained state
messages would be much more flexible. These would address the problem
of discrepancy between supposed and actual state.
Eventing and reporting, and an evolved storeconfigs concept are
something we're looking at, for sure.
Stay tuned, and of course, if you have time, patches are very much
welcome.
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvaug...@onyxpoint.com
phone: 410-541-ONYX
Re: [Puppet Users] managing gem files with puppet
what version does this occur on?
On Wed, Feb 3, 2010 at 11:52 AM, Gustavo Soares gustavosoa...@gmail.comwrote:
Hi everyone!!
I have noticed that if I am managing gem files with puppet ensuring a
specific version and the system has the gem 2 versions of that gem
installed, including the version that I am managing, puppet doesn't identify
that I have that gem installed.
For example:
package { fastthread:
ensure = 1.0.5,
provider = gem,
}
and on the server I have:
[pup...@localhost init.d]$ gem list | grep fastthread
fastthread (1.0.7, 1.0.5)
puppet says: (I am running puppet with --noop flag)
Feb 3 17:50:32 riovld37 puppetd[15489]:
(//gem::fastthread/Package[fastthread]/ensure) is 1.0.7, should be 1.0.5
(noop)
shouldn't puppet be aware that I have the package installed?
Thanks in advance,
Gus
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Plugins in modules with environments and the puppetmaster libdir
On Fri, Feb 5, 2010 at 3:29 AM, Thomas Bellman bell...@nsc.liu.se wrote: Nigel Kersten wrote: So facter plugins are kind of different, as they're not actually required to be in the puppetmaster libdir. Say this was a type/provider, and you wanted to add a new parameter, but only roll it out to your testing environments. Functions also have this limitation, by the way. What do you do then? If the version in the puppetmaster libdir doesn't accept that parameter, the manifest compilation will fail for clients who *are* getting a version of the plugin that supports that parameter. You lose... Well, there are a couple of things you can do to work around this limitation. For one thing, you could run a second puppetmaster process, perhaps on another port, or listening on another IP address, or perhaps even on another machine. Another thing you can do, is to run puppet with local manifests, instead of puppetd connecting to puppetmasterd, when developing the new version of the plugin. That's what I do. It does get a bit iffy if your manifests want to fetch files from the puppetmaster (i.e. that aren't in the modules namespace) though, or otherwise need to access files that are only available on the puppetmaster. Good news, though, is that the upcoming Rowlf version of Puppet is supposed to solve this for at least resource types. At least Luke has posted patches to the devel list that I gather will do that. But it will probably still be a problem for custom functions (I have somewhat volunteered to take a look at it, but I'm unlikely to find the time before Rowlf is supposed to be out). + puppet-dev Luke, how is this going to be solved in practice? The puppetmasterd will automatically add modules/*/lib dirs to it's own libdir in the context/environment of the current client? I'm thinking that in the meantime I may need to encode plugin versions in their names, so when a client's manifest contains a given plugin, it's always going to refer to that version, and I script something that collates all the lib/... directories into the puppetmasterd libdir. I feel dirty. /Bellman -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- nigel -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Making the new users experience easier
Michael DeHaan wrote: Just one more email and I'll let you go for a few hours :) One of the things I like to see in apps is that they are immediately intuitive and easy to use for new users. I think Puppet is really good here, but there's opportunity to make everything better. We want everyone to love Puppet from their first few minutes using it, all the way through to datacenter nirvana. With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? One of the ideas I had from cobbler was cobbler check which was a tool you could run to identify some of these problems. I'm not sure if it makes sense for Puppet, but it may do some things like say you appear to have DNS problems resolving this, you should try... and so forth. What else might there be? Obviously one of the things I'm going to be looking for are what questions keep coming up on IRC ... Are there mainly questions around puppetca? Should scaling be easier to set up out of the box and in the default configuration (right after RPM or deb install)? Are there easy additions or changes to the software we can make to make error messages clearer and self-resolving? Obvious things in the documentation/manpages we can clean up?(Aside: I think Puppet Dashboard has a LOT of opportunity to help with this too, so watch this space!) I'm going to be looking into this myself, but I'd love to hear from you. Any and all data is welcome. (If you'd prefer to reply personally or talk over IRC, that's fine too.) Thanks! --Michael Hey Mike, SSLSSLSSLSSLSSL... SSL, it 'makes my brain bleed' as plathrop of digg once said. SSL has probably caused more suicides than drugs, first semester at MIT, and chronic depression combined. I'm not sure anything can be done about it though, that is the sucky part. I'm not sure any programmatic check is going to solve the difficulties associated with SSL auth. Maybe better error messages such as CN does not match DNS name, rather than whatever it says now (can't even remember). Everything has already been mentioned in this thread that stumps beginners, but as far as troubleshooting, RI Pienaar (Volcane) wrote up the best puppet troubleshooting doc I have seen yet as a blog post over at devco.net. I think maybe RL should ask him if they can throw it on the wiki or something. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L'ennui est contre-révolutionnaire -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Making the new users experience easier
On Feb 5, 2010, at 4:06 AM, Nicolas Szalay wrote: Le mardi 02 février 2010 à 12:08 -0500, Michael DeHaan a écrit : Just one more email and I'll let you go for a few hours :) Hello puppeters One of the things I like to see in apps is that they are immediately intuitive and easy to use for new users. I think Puppet is really good here, but there's opportunity to make everything better. We want everyone to love Puppet from their first few minutes using it, all the way through to datacenter nirvana. With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? To join Peter : SSL. SSL is just a pain in the a**. As you said, some don't want to know about ruby webservers in detail, some don't want to know about SSL. Tell more in the beginner's guide about DNS, and the need to have a clean DNS for puppet to work fine. While getting started I had some problems. 1) I couldn't find a simple skeleton puppet configuration. I tried the tutorial, but there's lots of things that can go wrong, and figuring out what's wrong can be be a pain if you don't know what you're doing. A sample.tar.gz that has a module that does nothing but create a file in /tmp would be really helpful. Just getting a configuration that works and does something can be rather hard. 2) DNS: My setup was small and simple, so I've been using dnsmasq for DNS and DHCP. Dnsmasq doesn't support cnames so the auto-generated cert name on the puppetmaster doesn't work. I suggest that all autogenerated certificates have an alias of puppet to make setup easier. 3.1) SSL: Adding another server to an existing puppet setup is rather difficult if you don't know much about SSL. Here's something that would be helpful although it might be too hard to be feasible: Make it possible to have a new puppetmaster get a signing certificate from an existing puppetmaster. Then you'd use a command on the master server that's something like this puppetca --sign --puppet-server newservername.localhost. and/or 3.2) Allow the generation of server certificates on the server like this puppetca --generate --puppet-server newserver.localhost In either of these cases I'd ask that the default is to give the certificate an alias of puppet. 4) Something nearly as good as 3 would be a shell script that uses ssh to login to the server as root and does the same thing using the openssl command. 5) Error ambiguity: sometimes it's hard to tell if an error is happening on the client-side or server-side. -Patrick -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Declarative style and processes
On Fri, Feb 5, 2010 at 11:04 AM, Ohad Levy ohadl...@gmail.com wrote:
you can do all of this stuff already today (maybe not naively).
a lot of people use functions to query or set values on some external data,
output from the function can define which resources get evaluated etc.
another option some people use is to set facter_xxx environment variables
instead of external puppet functions.
i do agree, that at the end of the day, the 30 minutes default time is
insufficient, if you want to make a lot of changes - e.g. at the end you
must wait 30 minutes between each state change (assuming you have many
clients and a few states).
so in this case, I have a gut feeling which says - use the best tool for the
job, maybe puppet is not the right choice on such cases.
Ohad
On Fri, Feb 5, 2010 at 6:34 PM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This hits close to home with something that I would love to see added to
the puppetmaster but haven't quite figured out how to describe until
recently.
I recently realized that, for a given environment, what you actually
have is a massive parallel program running across various nodes.
Therefore, what I would like in the puppetmaster is a set of
stored-state named semaphores.
They would work as follows:
Semaphore: DB=0 on the puppetmaster
node web_server {
if semaphore('semaphore_db') 0 {
include foo
include bar
}
}
node db_server {
include db
}
class db {
service { some_db:
ensure = 'running',
require = Exec['set_me_up']
}
exec { 'set_me_up':
command = 'do stuff',
notify = semaphore('semaphore_db', '=', '1')
}
}
So, what this would do, is to set the semaphore $semaphore_db to 1 only
if the exec properly executes (which means that the DB got set up
correctly) and then would only set it to 1 if it was not already = 1 so
that multi-state processes can be handled.
Then, once the semaphore has been set, web_server would include what it
needed to properly function.
Note that this is not a locking process, the normal run of puppet would
ensue and the state change would only be noticed on the next run.
This does lag things out over a few runs of puppet, but also (I think)
keeps the entire thing running the 'puppet way' by essentially setting a
cross-system state fact.
I figured that the semaphore call would be an TLS REST call back to the
master, or a separate lookup process if you wanted to offload the work
to a different system.
Thanks,
Trevor
On 02/04/2010 03:42 PM, Michael DeHaan wrote:
On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger john.bollin...@stjude.org
wrote:
On Feb 3, 3:08 pm, Michael DeHaan mich...@reductivelabs.com wrote:
Actually I think it can be done by leveraging an improved storeconfigs
and
the existing language.
I was wondering whether storeconfigs would come up. The problem I see
with that is storeconfigs, as I understand them, record the managed
resource states each host *should* have, not necessarily those each
one *does* have. What happens to my multinode deployment if at some
point in the middle, Puppet fails to apply a necessary resource state?
If Puppet fails applying a state, it should record the current state,
not the once and future state.
I'll dig into the schema of what it does now, but don't limit your
thinking based on what storeconfigs currently does or is,
think about what it can be.
Absolutely so, and that connects back to your earlier comments about
message buses. Messaging is the lifeblood of any kind of
orchestration technology, but there are a variety of message exchange
patterns, message implementations, and messaging options, many
combinations of which are viable. Some could reasonably be
characterized as push, but many others couldn't.
This is an software architecture statement, and architecture is
independent of execution and concepts.
Long term, I expect to see messaging will happen and can then play a
much wider role mainly for offline delivery implications
and routing. Though much can be hinged on present workings, whether
RESTful or RPCy (which, aren't all that different regardless).
However, first, small steps.
Any way around, there is a class of messages needed for this that
Puppet does not currently have: messages from clients advertising the
individual or collective state of their managed resources. The
absolute simplest form would be a reply to the Puppetmaster indicating
whether a catalog was successfully applied, but finer-grained state
messages would be much more flexible. These would address the problem
of discrepancy between supposed and actual state.
Eventing and reporting, and an evolved storeconfigs concept are
something we're looking at, for sure.
Stay tuned, and of course, if you have time, patches are very much
welcome.
- --
Trevor Vaughan
Vice
Re: [Puppet Users] Making the new users experience easier
On Fri, Feb 5, 2010 at 2:38 PM, Patrick kc7...@gmail.com wrote: Great info everyone, thanks for all the feedback.Look for a lot of improvements, especially in the documentation/example space soon. --Michael -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] why do I get ensure changed 'purged' to 'present' on a package when it is already installed
Hi all,
I have created a squid class that also installs squidGuard. When I
run puppetd I always get
notice: //Node[.xx.xxx]/squid/squid::install/
Package[squidGuard]/ensure: ensure changed 'purged' to 'present'
even though the package is already installed - why is this change in
package status happening as it then triggers my exec resource which is
only supposed to run the first time when squidguard is installed
(thereafter it is run as a cron job). So at the moment it is
triggered every time puppetd is run
exec { /usr/local/bin/getblacklist.sh:
subscribe = Package[squidGuard],
refreshonly = true
}
Regards
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] why do I get ensure changed 'purged' to 'present' on a package when it is already installed
On Fri, Feb 5, 2010 at 4:24 PM, tim_schofield t...@scoffer.net wrote:
Hi all,
I have created a squid class that also installs squidGuard. When I
run puppetd I always get
notice: //Node[.xx.xxx]/squid/squid::install/
Package[squidGuard]/ensure: ensure changed 'purged' to 'present'
running with --debug will show some useful information about the underlying
system calls being made. Run again in debug mode, then post the output (or
just the output that we care about).
also, what version of Puppet are you running? what platform?
even though the package is already installed - why is this change in
package status happening as it then triggers my exec resource which is
only supposed to run the first time when squidguard is installed
(thereafter it is run as a cron job). So at the moment it is
triggered every time puppetd is run
exec { /usr/local/bin/getblacklist.sh:
subscribe = Package[squidGuard],
refreshonly = true
}
Regards
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
