On Mon, Mar 9, 2015 at 11:55 AM, Bostjan Skufca < [email protected]> 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 [email protected]. > 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 [email protected]. 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.
