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 puppet-dev+unsubscr...@googlegroups.com. 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.
