On Thursday, 19 March 2015 01:51:17 UTC+1, Felix Frank wrote: > > On 03/19/2015 01:08 AM, Bostjan Skufca wrote: > > - both agents request the same environment: one master returns the whole > system catalog, the other just bits to manage primary puppet > > > I don't quite see why the agents would have to use identical environment > names. Could you perhaps also approach your problem by making the secondary > agent use <environment>-meta or something in that vein? >
It could be done, but having single puppet master kind of defies the purpose. If there are multiple masters, having different environment names for same environment is redundant. But I know this is a personal opinion. - on puppet masters server this means duplicate environment data/module > repository clones > > > But does the secondary agent even require a substantial amount of data and > modules etc.? > Not really. > - puppet is a power tool, and irresponsible users that rush into using it, >>> should not stand in the way of progress >>> >> Again, that's just a thing you can say. It sounds very impressive, but >> what does it mean and how does it apply to reality? Irresponsible users or >> not, we're the ones that get flack for it, that need to support it, that >> have crying users and get a bad name because "Puppet nuked my system". It >> will never be their fault, it will always be the fault of the system. >> > > Huh? :) > Users that have systems in production they do not understand, and then > slapping puppet on top of it using modules they do not understand, bricking > the service (or the system) and yelling "Puppet nuked my system" belong to > the h(w)all of f(sh)ame, and not to the decision-making process about > puppet features. Please do not take this personally or as offensive, as I > am having a rather nice chuckle here, with many analogies springing up on > "this is the tool's fault, not mine" subject :) > > > There is such a thing as UX engineering. You seem to be under the > impression that it is about catering to mediocre technicians. That is just > not true. > UX engineering I support, fully. > Anyhow, I think everybody has understood that you intend to add this > functionality for use by the most advanced users only, but if this includes > but 10% of all users, and only an insignificant percentage of those has any > use for this whatsoever, then the value of maintaining it upstream appears > unimpressive. > I agree somewhat, as we are not talking about breaking any legacy compatibility, instead we are talking about making things more general. Actually having directory environments as an (default) implementation of EEL would be more in line with where puppet is heading (think ENC which delegates this functionality to the user) than having it as a built-in only option. Another argument could be made by comparing number of available configuration settings (around 244 ATM) to what I currently use in puppetmaster.conf - 10-15, depending on installation. That does not mean I consider all other config settings unnecessary, in fact it is quite the opposite. Now I know that "feature" is not the same as "configuration setting", but this argument speaks to the puppet's configurability as being a good thing. Power users are the ones that usually push the limits of things, and if reimplementing a feature in a more general way that does not hinder performance of general customer base, while offering advanced users what they need, and at the same time making maintenance simpler (remember, this would be implemented in a more general way), then I think this is a win-win situation for everybody. I think my note about suggesting git's way of providing "plumbing and porcelain" interfaces as good approach still stands. Best regards, b. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5f8068ac-186c-41ee-b671-134fa77a1b46%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
