On Monday, 16 March 2015 14:55:23 UTC+1, John Bollinger wrote: > > > > 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 never said anything about masterless. You are right about two puppets and separate masters. Going masterless just shifts deployment work from one to multiple locations, though it could be done.
> - 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. > > Correct. > > - The problem you then encounter, I take it, is that you have > collisions between the environment names associated with the (erstwhile) > two masters. > > This was never a problem, as masters are separate processes (for resiliency reasons) and having identically named environments was never an issue. > > - The solution you propose is essentially to introduce namespacing for > environments, via dynamically-selected environment (root) directories. > > I would not agree on this point, as namespacing suggests you can reuse the same name in different contexts within the same process. This is not the case here. What is proposed here is environment location discovery service - SUPPOSEDLY it should return the same path every time the same environment name is passed to it. I say supposedly because that would be the intended use case, but I imagine that this locator might return whatever user wants it to return, though currently I can not imagine a use case where one would want to serve the same environment from multiple separate directories. What is written in the previous paragraph only applies to single puppet master process. If there is another puppet master process on the same system that resolves environments to paths in different manner, that is no concern to the other puppet master. 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. > This might be solvable with single puppet master process and multiple environments, as you have suggested, but again this undermines redundancy (single puppet master is easy to manage manually if something happens, multiple - not so much fun anymore) and duplicates environment data (two clones of the same repos) which I am also trying to reduce. 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/6675ce0a-5480-4b93-b9cf-798bfc4fd9fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
