-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline....
>> - - I would have it be a stand alone application, not an add-on to the >> primary puppet daemon. The reason for this is that many of us use puppet >> from cron instead of as a daemon for various reasons. > > Interesting yeah, in that case the transport then becomes SSH though? > Seems to be redundant in that configuration. - -THV- Agreed, but SSH seems to be a bit more reliable than puppet as a transport layer due to user error. I've had cases where I implemented something that worked fine on 20 nodes but then, on node 21, hung for some reason and could not recover. Puppetrun, in this case, would be completely useless. This is a simplified version of reality, but it happens as not all variables can be successfully tested, or known, in any given environment. > > We're attempting to provide a reason to not use cron :) - -THV- Why? Puppet currently potentially uses quite a bit of memory on a large manifest set and seems to work great out of cron with no adverse side effects. > >> >> - - I do have to wonder how this is much different that cobbling together >> the results of puppetlast (to get the nodes that have checked in) with >> some sort of parallel SSH solution (besides the fact that you're using >> the puppet certs instead of SSH keys). > > It would resemble that... but the idea here is we want to leverage > those that have already checked in > and the existing comm path. I understand your use case though... in > which case, I think just using a parallel > SSH (in that case) if you are ok with that, solves the problem... or > continuing to use cron. > > Here it is really about replacing puppetrun ... :) - -THV- I definitely understand this, but I suppose that I'm questioning the existence of puppetrun altogether. It's relatively useful, but I'm guessing that one of the main things that most people do with puppet is to set up SSH. As such, you're re-inventing the wheel with a questionable gain for the effort. >>> >>> Requires no additonal ports, setup, or config files -- use existing >>> puppet listening capability and puppetca, just a /usr/bin app >> >> - - I don't particularly agree with this for the reasons listed above. > > Don't follow, can you elaborate? - -THV- No additional ports means an additional listening thread inside of puppet itself. If we were using Ruby 1.9 with native threads, then this wouldn't be a problem but the way it is currently implemented I don't have much faith that a hang in one part of Puppet wouldn't cause the listener to hang as well. I could be wrong :-P. The reduction of setup and config (as it is now) makes sense. >> >> - - Are there example use cases of this? It sounds useful, but my minimal >> ralsh experimentation didn't really prove to be greatly fruitful. > > I'm thinking more about querying for states of things than making changes. - -THV- Ah. This makes sense. I have had some problems with ralsh in the past not picking up my complete manifest. I'll try to come up with some concrete examples if possible. > >> >>> Be able to run shell commands for things that are one offs (emergency >>> security power down now) >> >> - - This comes back to the common framework. I'm going to want to be able >> to do this regardless of whether or not puppet is actually running. I >> may want to do this (or something like it) because puppet is hung for >> some reason. > > I understand, yeah. In this case, distributed SSH may be your friend > if you don't want to run cron and don't want puppet to listen. > Otherwise it kind of is cross-purposes with the idea of fixing > puppetrun... and extra management of SSH keys is overhead when > puppetca is there for that purpose. > > I know what you're saying though... - -THV- I think that the point I'm so blatantly failing to make is that puppet isn't a tool for one-offs and isn't advertised as a command and control infrastructure. I suppose that my *NIX roots are showing in that I shy away from adding features to a tool that I can easily do with something else. As I mentioned in this response, one of the first things people are probably going to do is to get a working SSH infrastructure going. Once this is done, you have everything you need to do one-offs. Thinking of some common use cases: 1) I screwed up resolv.conf - Puppet's not going to work unless you pre-mangled /etc/hosts, SSH it is. 2) I screwed up /etc/hosts - Puppet's not going to work. Back to SSH. 3) DNS is broken - See #1 4) I hosed my PKI certs - See #2 In these four cases, you *have* to have a working SSH infrastructure that spans your entire puppet base. So, after all of this rambling, perhaps you may want to have the new tool be transport pluggable. Support both SSH and Puppet in the present and perhaps grow to support things like mcollective under the same abstracted administrative interface. Thanks, Trevor - -- 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) iEYEARECAAYFAkt2cOMACgkQyWMIJmxwHpSKhACgh6QXNkaQMyh7+tdL33QTIqZm 66AAn0g379T1RQxA0vrJLGXtdoG8AWhj =tAPZ -----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.
