On Monday, 16 March 2015 14:01:58 UTC+1, Daniele Sluijters wrote: > > Hi, > > It would really help if you elaborated on your use cases in this thread. I > read the one message you linked but I'm still not sure about it and I don't > feel like reading the whole other thread to get context. If you propose a > feature part of that proposal should be a rationale and intended use cases. > Preferably with a comparison of how this makes things better compared to > the old setup. >
I specifically linked to a post (and not the whole thread), it should be more or less context-free. I would rather not copy-paste the whole thing here, as next message (not yours specifically) would accuse me of copy-pasting instead of linking:). Aaron Stone provided another use case in this thread, couple of posts ago. Here is my use case summarized: - each node has two puppet agents installed, they manage one another - each of these agents talks to separate a master process - both agents request the same environment: one master returns the whole system catalog, the other just bits to manage primary puppet - on puppet masters server this means duplicate environment data/module repository clones - this is inefficient as secondary puppet only manages first puppet and thus utilizes one separate module from whole repository - both puppet masters use the same ENC already With this feature, I could downsize the management to: - single environment repository, with environment.conf for primary and environment.conf-secondary for secondary puppet master process - (please note that I have already patched puppet master so that it supports configurable name for "environment.conf") - both would use the same modules repository - they would have separate manifest definitions (one defines the full system, the other is quite simple, just puppet), kept in separate directories, but managed within the same git repo What is gained by this feature, for me? - If node is in environment X, I can go to /etc/puppet/env/X and do a single git pull in there, and configuration is deployed - without this, I would need to do additional step: go to /etc/puppet-SECONDARY/env/X and do another git pull This is my use case, and this feature would be only one part of the whole equation. Another use case would be environment location verification: - suppose you have multiple departments using puppet environments - environments are prefixed with dept1_, dept2_ and so on - departments upload their environments into their dedicated directories, one per department, say /etc/puppet/env/dept1/dept1_prod would be the final path to environment, and department1 has access to this directory: /etc/puppet/env/dept1 - you have you puppet master configured with multiple directory environment paths: .../env/dept1:.../env/dept2:... - as long as everyone is playing nice, everything works - now imagine that dept1 accidentally creates environment dept2_prod, which should belong into dept2/... subtree - with current implementation (dir environments) it is impossible to check if environment directory is actually the one that was initially indended With EEL, you could easily check this, and correctly ignore .../env/dept1/dept2_prod environment, as environment prefix "dept2_" would be invalid in .../env/dept1/ directory. > On Friday, 13 March 2015 16:52:13 UTC+1, Bostjan Skufca wrote: >> >> For such an occasion I like to say that, yes, doing "rm -rf /" is bad, >> but as a sysadmin I still want to have this tool available. :) >> >> Maybe puppet is becoming complex enough that Puppet Labs should think >> about classifying configuration settings into two categories: basic and >> advanced. This one (EEL) would definitely fall into advanced category, and >> directory environments should be advocated/documented as primary way to >> create/use environments. >> >> Anyway, what I am trying to say is: >> - puppet should not be holding power users back as a sacrifice for being >> nice to novices; >> > That's a very broad argument that can be applied to the whole universe. > It's not backed up by facts or any data, it's just a "thing you can say". > I agree this is broad. But it still applies if features are rejected (your words, see below) because users can shoot themselves in the foot. > - puppet should strike a good balance between both extremes, by means of >> feature implementation and documentation organisation; >> > You can't strike a balance between both extremes by having both, you need > to meet in the middle. Which means maybe not all the features and maybe not > the greatest documentation but enough of both so people don't shoot > themselves. > I thoroughly disagree here. Take git, for example. It provides both, the so-called "porcelain" interface, which covers majority of general use cases, and for power users there is the "plumbing" interface, which can be used to achieve advanced integration or functionality. However I do recognize the danger of becoming everything-but-the-kitchen-sink implementation of configuration management, but I do not see this feature as step towards that direction. > - achieving such a balance is not easy, I admit; >> > Balance means weighing things against each other. Having both all the > features and excellent documentation and making sure that people can't > shoot themselves is very very very hard. It's precisely because of this > that we decide to reject features at times. > I understand. > - 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 :) I would understand this accusation if manifest specified "ensure => present" but puppet would remove the file/package/whatever. But if this removal happens because of some convoluted module/profile/hiera/yaml interaction which user is too lazy/st**id to comprehend, but it resolves to final "ensure => absent", then the problem is not the tools functionality, but users incompetence. But it is hard to call paying customers incompetent, thus I understand your clutch. However having simple features rejected will make existing users, which reach the borders of puppet's functionality, look towards other solutions, as I am sure you understand. 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/4bd5995b-1459-4e00-9c87-855a08d6c5c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
