On Wednesday, March 18, 2015 at 7:08:17 PM UTC-5, Bostjan Skufca wrote: > > > > 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. >
You did link to a specific message. It did not adequately describe what you wanted. At least, I clearly didn't understand what you were after from just that post. > 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 > Why? You have two separate masters managing disjoint aspects of the target machines, via disjoint sets of agents. Why do they need (or even want) to share *anything*? > - this is inefficient as secondary puppet only manages first puppet and > thus utilizes one separate module from whole repository > Right. So what is the advantage in them sharing anything at all? > - both puppet masters use the same ENC already > > Why? Each master needs to classify nodes altogether differently than the other. How does it make sense for them to use the same ENC? Not that it really matters, I guess. > 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") > Wait, are you trying to get rid of your need for separate `environment.conf` files, or not? It sounds like you intend to continue with that mod, but if so, then I don't see why it doesn't already address all the issues you describe. John -- 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/9644d2aa-5d95-4935-b7f7-216addbc79ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
