On Thu, Feb 4, 2016 at 11:41 AM, Mateus Caruccio <
[email protected]> wrote:
> 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.
>
>
environment is a generic image concept so it makes sense for s2i to have a
concept of environment injection.
templates, transformation of templates, and destination for transformed
templates, are all framework specific (based on how the framework consumes
configuration data, how the assemble script processes it, etc) concepts, so
they do not make sense as first-class s2i concepts, imho. You'd have to
enforce that every assemble script respected that templates directory, and
define what should be done with templates found in that directory.
I don't see why just defining this at the assemble level ("the php assemble
script looks for templates in location FOO, it transforms them using XYZ,
and places the result in location BAR") isn't the right solution.
The problem of certain templates having additional dependencies which must
be installed as root only furthers this argument imho, that it's an
image-specific concept and not an s2i-generic one.
>
>
> *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
>
>
--
Ben Parees | OpenShift
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
