On Mon, Mar 9, 2015 at 11:55 AM, Bostjan Skufca < bostjan.skufca.w...@gmail.com> wrote:
> On Monday, 9 March 2015 17:33:27 UTC+1, Joshua Partlow wrote: >> >> On Mon, Mar 9, 2015 at 9:05 AM, Henrik Lindberg <henrik....@cloudsmith. >> com> wrote: >> >>> On 2015-09-03 14:54, Felix Frank wrote: >>> >>>> On 03/09/2015 02:16 PM, Henrik Lindberg wrote: >>>> >>>>> It would be splendid if we could define modulepath paths with >>>>>> $environment as variable part of path, like this: >>>>>> modulepath = /path/to/$environment/modules >>>>>> manifest = /path/to/$environment/manifest2/ >>>>>> >>>>>> Would there be any interest for this feature? >>>>>> If this is implemented for modulepath setting, maybe it should be >>>>>> appropriate to implement it for manifest setting too? >>>>>> >>>>>> >>>>> This scares me a bit. It looks like it has potential to open the can of >>>>> worms known as dynamic environments we managed to put the lid on with >>>>> directory environments. Will have to discuss if this can used to do >>>>> harmful things. If allowed it could only be allowed inside an absolute >>>>> path. >>>>> >>>> >>>> Agreed, there might be security implications. >>>> >>>> I also fail to see the value in that. Do you mean to allow an >>>> environment to extend itself to a whole different file system tree? >>>> Wouldn't that just be horrible for organizing things? >>>> >>>> >>> The use case was to use one location for two master instances without >>> having to have two copies, and without having to have a modulepath that >>> includes the name of the environment (which is possible now). >>> >>> Not sure that use case is worth the potential problems. >>> >> >> I'm not really following the use case either, Bostjan. I'm not >> understanding what benefit having the $environment interpolate is giving >> you here, since $environment is already selected to get to >> environment.conf, the path is already pre-determined. >> > > 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. > > If all above seems overcomplicated and overengineered, there might be > something about me being more lazy than others and thus putting in more > work upfront so I do not have to do it later (fixing broken puppet > installations manually). If so, please tell me:) > > > It was PUP-3162 where we ultimately decided to whitelist for $environment >> interpolation, and the only setting that made the cut was config_version. >> I don't think we want to change that because it makes the pathing harder to >> think about and may have other unforeseen consequences in the settings and >> environment handling. >> > > I can understand that. > I believe we are talking about two contradicting concepts here: > a) directory environments assume all environment-related content is under > main environment directory, except for common modules (basemodulepath) > b) power users know what they are doing and would like to interpolate > variables to optimize their workflow > > I already work around that when installing puppet, as it gets patched with > mentioned changes automagically. And these changes are only needed on > master, though. > > > ALTERNATE SOLUTION > Since I posted original message, I have come up with a better solution > actually. Forget the interpolation patch. I've introduced new puppet > configuration variable, called "environment_conf_filename", which enables > customization of "environment.conf" filename. > > One puppet master now uses environment.conf-1, the other > environment.conf-2, from the same directory (and same git repo). > > Content of these files now looks like this: > ### environment.conf-1 > manifest = manifests-1 <-- full node definitions, including module for > puppet-2 > modulepath = modules/ > > ### environment.conf-2 > manifest = manifests-2 <- separate manifest, that only includes > definition of puppet-1 installation for all nodes > modulepath = modules/ > > Now all content can reside in the same git repository, and puppet masters > still do not interfere with each other, which is splendid. > > Since solution is already done (works for me), I am moving this thread to > "comment/criticise my setup", ok? If you have opinion about this, please > speak up. > > The change you've proposed seems extremely specific to your use case; do you see this feature being usable for anyone outside of your environment? > > And thanks for responses, > 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/5ee4b679-af17-438d-9a5f-81c01241949b%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/5ee4b679-af17-438d-9a5f-81c01241949b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Adrien Thebo | Puppet Labs -- 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/CALVJ9SLVSPRrz-HSerxTT1FGShZPx3twW8cjUhE_dNO4nME2fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
