Runtime execution (aka how to parametrize execution)

[containers-tools]

Runtime execution (aka how to parametrize execution)

[praiskup]

Guys, have you looked at https://github.com/devexp-db/cont-lib project?
The container runtime parameters are already done there for some time.

What is the benefit to solve this in 'cct' once more ;)? Example of usage
is in https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/postgresql

Both environment variables and additional "descriptor" files are already
supported.

[vpavlin]

@praiskup Do you have any docs?

The point is to get rid of bash scripts which is not very nice solution to anything. Also, have you announced it anywhere? This is the firts time I see your tool.

[praiskup]

Docs are TBD, it was mentioned on appinfra - and it is part of
rhscl-dockerfiles project/{rhel,fedora}-postgresql.

So far it was about do it for PostgreSQL container and about "cut out
things that are worth doing consistently in other images". Something like
DRY.

For docs I recommend to look at:
https://github.com/devexp-db/cont-lib/blob/master/configure.ac
https://github.com/devexp-db/cont-lib/blob/master/share/cont-lib/cont-lib.sh.in

The point is to get rid of bash scripts which is not very nice solution
to anything.

This is quite strong opinion TBH :).

[vpavlin]

It's an opinion of the ex-maintainer of initscripts..I'll take a better look later today, thanks

[rwngwn]

@praiskup
I looked at that tools and it seems that is really good for shell scripting, and I think that you can just implement a module for cont-lib and run it as a part of cct. and this probably is the way we want to go. Just to have anyone to use his favorite engine, libraries, frameworks and combine them to an ideal tool. This approach enables anyone to make a small step which can be used by almost anyone.
also we really want the tool to be used for configuring containers in a docker build as in docker run.

[vpavlin]

@praiskup I agree with @l-d-j that there should be possibility to have cct plugable so that you can use whatever you want to implement your configuration bits..

But to answer your question about "why is bash bad idea?" - You had to implement even a simple split function for your project because you are using bash - every single language I worked with so far has that, only in bash you need to do that over and over again for every project you create...and that's why I think shell scripts are bad idea for general commonly used framework(s)

[praiskup]

I basically see your point even though the 'splitting' example is not precisely
spelled. Its not "just" split, there is also "escaping" implemented (and
already tested in testsuite). There was nothing more needed during the time I
looked at it, so .. so for my PostgreSQL usecase is anything else
overkill (and it can be for other containers the same).

If I really need something more complicated, there is no problem
optionally plug 'cct' or other already existing configuration tool in.

[vpavlin]

Back to the original topic...

I am not entirely sure if this changed or not, but back then in dock when run in OpenShift in a container we passed the configuration through environment variable - but not a single config option - whole content of configuration serialized into a single environment variable - I didn't like it back then, but it was actually the only way how to pass the config through OpenShift because you are not able to get a file to OpenShift infra and mount it in container. What is your opinion on this? Would it make sense to have it as an option next to the two @goldmann described?