Yeah, that's exactly the use case I'm talking about. Since there's .sti/environment, it seams to me a natural path to have .sti/templates/ containing a mirror-like tree, i.e. everything inside .sti/templates/<tree> becomes /<tree> inside the container.
*Mateus Caruccio* Master of Puppets +55 (51) 8298.0026 gtalk: *[email protected] <[email protected]>twitter: @MateusCaruccio <https://twitter.com/MateusCaruccio>* This message and any attachment are solely for the intended recipient and may contain confidential or privileged information and it can not be forwarded or shared without permission. Thank you! On Thu, Feb 4, 2016 at 2:32 PM, Erik Jacobs <[email protected]> wrote: > Hi Mateus, > > At this time each image kind of handles this differently, as best I can > tell. For example, the JBoss EAP image will look for settings.xml in the > code repository and substitute that instead of the built-in one > (over-simplifying). > > The issue is how you would do this in some kind of "generic" way. EG: how > do I inform any builder image that it should place file X from the code > repository into location Y, possibly creating a directory (eg: mkdir -p) in > the process... > > Would you say the following user story is accurate? > > As a user/developer with OpenShift > I want to place a (config) file in my source code repository > And through some mechanism tell the S2I process to place this file in a > specific location > > Env vars would be the "values" of the config options, as opposed to the > config itself, I would think. For example, the "custom config mechanism" > might allow you to put a foo.ini file in a specific location, and that file > might contain a GETENV-type reference which would be substituted by an env > var of CONFIG_VALUE_FOO_THING=BLAH > > Is that all an accurate assessment? > > > Erik M Jacobs, RHCA > Principal Technical Marketing Manager, OpenShift Enterprise > Red Hat, Inc. > Phone: 646.462.3745 > Email: [email protected] > AOL Instant Messenger: ejacobsatredhat > Twitter: @ErikonOpen > Freenode: thoraxe > > On Thu, Feb 4, 2016 at 8:23 AM, Mateus Caruccio < > [email protected]> wrote: > >> Hi Erik. >> >> That may work, but it won't be able to substitute runtime env vars. Also, >> it adds an extra step for something that should be simple: custom configs. >> The point here is not my specific use case. I'm looking now for a more >> generic way to allow users to define/overwrite container config in a user >> friendly way, like a simple file placed in a predetermined place inside the >> code repository. >> >> The I see now is what could be used as a simple template engine, that >> adds little or no impact on already available docker images. >> >> Regards, >> >> >> *Mateus Caruccio* >> Master of Puppets >> +55 (51) 8298.0026 >> gtalk: >> >> >> *[email protected] <[email protected]>twitter: >> @MateusCaruccio <https://twitter.com/MateusCaruccio>* >> This message and any attachment are solely for the intended >> recipient and may contain confidential or privileged information >> and it can not be forwarded or shared without permission. >> Thank you! >> >> On Thu, Feb 4, 2016 at 12:50 AM, Erik Jacobs <[email protected]> wrote: >> >>> Hi Mateus, >>> >>> Maybe I'm misunderstanding the problem, but would the secrets mechanism >>> not work for this? You could have the ini file be a secret which would be >>> attached/mounted into the pod at run-time and could be in that folder as an >>> .ini file... I think? >>> >>> Ben? >>> >>> >>> Erik M Jacobs, RHCA >>> Principal Technical Marketing Manager, OpenShift Enterprise >>> Red Hat, Inc. >>> Phone: 646.462.3745 >>> Email: [email protected] >>> AOL Instant Messenger: ejacobsatredhat >>> Twitter: @ErikonOpen >>> Freenode: thoraxe >>> >>> On Mon, Feb 1, 2016 at 4:43 PM, Mateus Caruccio < >>> [email protected]> wrote: >>> >>>> Hi. >>>> >>>> I need to run newrelic on a php container. Its license must be set >>>> from >>>> php.ini >>>> or >>>> any .ini inside /etc/opt/rh/rh-php56/php.d/ >>>> . >>>> >>>> >>>> The problem is it need >>>> s >>>> to be set on run time, not build time because the license key is stored >>>> in >>>> a >>>> n >>>> env var. >>>> >>>> What is the best way to do that? >>>> Wouldn't be good to have some kind of template processing like [1]? >>>> Something like this: >>>> >>>> for tpl in $PHP_INI_SCAN_DIR/*.template; do >>>> envsubst < $tpl > ${tpl%.template} >>>> done >>>> >>>> There is any reason not to adopt this approach? Is it something origin >>>> would accept as a PR? >>>> >>>> [1] >>>> https://github.com/openshift/sti-php/blob/04a0900b68264642def9aaea9465a71e1075e713/5.6/s2i/bin/run#L20-L21 >>>> >>>> >>>> *Mateus Caruccio* >>>> Master of Puppets >>>> +55 (51) 8298.0026 >>>> gtalk: >>>> >>>> >>>> *[email protected] <[email protected]>twitter: >>>> @MateusCaruccio <https://twitter.com/MateusCaruccio>* >>>> This message and any attachment are solely for the intended >>>> recipient and may contain confidential or privileged information >>>> and it can not be forwarded or shared without permission. >>>> Thank you! >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> [email protected] >>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>>> >>>> >>> >> >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
