On Thursday, March 12, 2015 at 5:33:35 PM UTC-5, Bostjan Skufca wrote: > > > > On Thursday, 12 March 2015 20:30:23 UTC+1, John Bollinger wrote: >> >> >> >> On Wednesday, March 11, 2015 at 11:56:44 AM UTC-5, Bostjan Skufca wrote: >>> >>> Hi all, >>> >>> I would like to propose a new feature for puppet master: External >>> Environment Locator (EEL) >>> >>> The main objective would be to make locating puppet environment >>> locations more flexible compared to directory environments. Basic >>> functionality would facilitate usage of external program to convert >>> environment name to corresponding path (directory or environment >>> configuration file). >>> >>> >> >> Greater flexibility is not a justification in itself. Just because I >> wouldn't use such a feature doesn't mean it's not worthy, but I would like >> to hear a bit about how you imagine using it, and in what other situations >> you imagine it being useful. >> > > John, please see here (in 9th message on this other thread I explained my > use case), this is a direct link to that message: > https://groups.google.com/d/msg/puppet-dev/Akk8vZBPuRs/sB71tK5ow1UJ > >
So I guess, then, you're talking about this: The main motivation for my setup is: > - if something happens to puppet upgrade and puppet fails to work, I do > not want to ssh into nodes to manually fix the problem. > - Even "mcollective" is not proper solution here (usable for quickfix, > yes), as some nodes might be down and will have to catch up eventually > > To achieve this, I have two puppets (installed in dedicated separate dirs > under /usr/local/puppet-1 and /usr/local/puppet-2). If, for the sake of > argument, we forget that puppet-1 manages the whole system except itself, > you can see the redundancy here (puppet-2 is served a special config > catalog that only includes puppet-1 installation/upgrades). Each puppet > definition is in own puppet module, so nothing is shared there. > > Up to this point it is all nice, and works, if you presume you use > separate manifests for each puppet, for the same node. The annoying thing > becomes when I have to manage manifests in separate git repos, at least > partially. > I think I'm having trouble understanding this scenario, or how the proposal helps, or both, so correct me where I'm wrong: - I guess you have separate agents on each machine and separate masters to serve them, at least currently, for I can't imagine why you would want to go this direction if you were running masterless for even one of the two Puppets you describe. - I infer that you want to consolidate the masters but not the agents, for consolidating the agents would eliminate the resiliency benefit that inspired this approach in the first place. - The problem you then encounter, I take it, is that you have collisions between the environment names associated with the (erstwhile) two masters. - The solution you propose is essentially to introduce namespacing for environments, via dynamically-selected environment (root) directories. If all that's correct, then why does the ENC ability to designate node environments not sufficiently meet your needs? Instead of using same-named environments in different directories, you could instead use different environment names to separate the environment group for one purpose from the environment group for the other. Example: "production" and "production-puppet". That has the additional advantage of keeping all the external classification logic in the same place, instead of splitting it across two separate programs. 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/11e8554b-e476-45e6-9a03-068b44781d35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
