On Sat, Feb 13, 2010 at 4:29 AM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > -----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.
We need to work on that. I don't want to constrain our conceptual ideas too much by current limitations. Anyway, if you are able to stagger node rollouts according to custom workflow you gain two capabilities: one -- you can not role out your infrastructure all at once, for safety reasons (even if you do have a good 'stage' infrastructure). For instance, update just some of these hosts, and then update the rest. two -- you have a nicer scaling puppetmaster as you have more control on when they check in and put load on the server, rather than having the spike happen at intervals (and without you having to manage these intervals with cron). While we're working to speed up puppetmaster and also make it scale out easier, just being able to stage rollouts centrally combined with that can offer some nice performance opportunity. Finally three (amongst our capabilities </spanish inquisition sketch>), you don't have to manage your crontab for puppet in your image/kickstart/etc, because it can all be centrally managed and not up to the client. Is that going to work for all use cases? Probably not, but if you have something you like, you can definitely continue to use it. I'd like to have better control over when things run from a central server perspective myself, so I could do things faster at times, have more fined grained control, etc. > > - -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. Perhaps... I agree with your pluggable transport things below. It also seems that (at least from what I gather) that not everyone /does/ distribute SSH keys. (They might rely on serial consoles, for instance). > > - -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 real idea is not have hangs in that part of Puppet, isn't it? :) I'll keep that in mind as I'm doing it. I'm sure there will be some corner cases here and there that we'll have to straighten out. > >>> >>> - - 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. *nod* That would be just one of many small features. If you wanted to use SSH or serial consoles for that, you still could, of course. For those that don't have that, having a distributed system out of the box that can do that is pretty darn useful.... and we can get that more or less for free. Best practices, as you say, should probably imply having a backup plan. > 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. Agreed. Might not get that in initially, but we should keep it in mind and do the very first one as a plugin, to make room for the rest. -- 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.
