On Jun 18, 2012, at 4:41 PM, Wolf Noble wrote: > No, it's not the easiest way to break your environment. but it is a direct > line to future obfuscated breakage, red herrings, and new and exciting ways > to waste lots of engineers' time trying to suss out what in the the last N > changes broke $package. > > Not taking that into account will arguably lead one to making bad design > choices. Aren't we supposed to be lazy and try to NOT shoot ourselves in the > foot unexpectedly?
First of all, do you know this environment better than I do? Are you in a position to tell us that this risk is worse than another? I can assure you that the risk of using a completely different configuration manager/ecosystem side by side with puppet is much risker than using the fine-grained control to do exactly what we know and have tested to work properly through an extensive QA process. I am amazed that people are very interested in telling me that I should implement an external system to replace puppet, rather than allow fine-grained control of triggers. This is simply amazing. Sure, it's much better to run two different configuration management systems interlaced with each other. Nothing could go wrong with that, right? *headdesk* >> Same software, same management functions, same configs… just a different >> permissions change on new installations. Should I really duplicate the >> entire module, and manage all changes in both places? And forever try to >> manage which host should be in which generation? > > There's many ways of doing this… A case statement tied to a version number, > or some other fact will get you this.. > Aren't you pretty clearly stating that this old generation IS different than > the next generation? How is puppet supposed to KNOW the difference between > the two? It isn't. That's the point. At the puppet level there is absolute no difference. We simply want new installations to have the new permissions. Old installations are going to be upgraded by hand, outside of puppet. We desire a period of overlap, where new installations can be set up correctly with the new permissions WITHOUT having the older installations fall over. During this overlap period, any change to the installations will be applied to both old and new. Having "replace => false" not apply to mode, owner and group would meet our needs -- but the general-purpose fix could apply to a lot more situations. > I've yet to see a satisfactory implementation of 'do what I mean, not what I > say'.. but then again, I think that's why we're driving the computers and not > the other way around… This has nothing to do with "do what I mean". I am being very, very specific about what I say. I want to be more specific than puppet allows me, and people are fighting this idea all over the place. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
