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 [email protected]. 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.
