Mechanism for enabling SCL packages.

[GrahamDumpleton]

Currently the enabling of software collection packages is triggered by virtue of the following in sti-base.

ENV BASH_ENV=/opt/app-root/etc/scl_enable

The scl_enable file for sti-python includes:

# IMPORTANT: Do not add more content to this file unless you know what you are
#            doing. This file is sourced everytime the shell session is opened.
# This will make scl collection binaries work out of box.
unset BASH_ENV PROMPT_COMMAND ENV
source scl_source enable python27

The problem is that the activation only occurs when a bash shell is created.

This means that doing the following will result in the wrong Python version being run.

$ oc rsh wsgi-hello-world-1-3yi15 python -V
Python 2.7.5

The better way to handle this would be to use an ENTRYPOINT script of:

#!/bin/bash

set -eu
cmd="$1"; shift
exec $cmd "$@"

The sti-base does actually have such a script and defines:

ENTRYPOINT ["container-entrypoint"]

This means that the activation technically should occur when doing above rsh as the command will be child to the entrypoint script, but it isn't.

This is with the RHEL images from registry.access.redhat.com. So it could be out of date images there, although the the container-entrypoint script does I recollect exist in them.

Can't verify right now as OSE cluster is broken and my home Internet is also borked right now so can't check CentOS images even.

Is the container-entrypoint as ENTRYPOINT supposed to ensure SCL packages are enabled?

Are the RHEL images on registry.access.redhat.com up to date?

[GrahamDumpleton]

Confirmed that if entrypoint is meant to allow enabling of SCL, it isn't working on CentOS images either.

$ oc rsh wsgi-hello-world-1-rqiy2 python -V
Python 2.7.5
$ oc rsh wsgi-hello-world-1-rqiy2 bash -c 'python -V'
Python 2.7.8

I might also add that I think the nss_wrapper setup should be in an entry point script as well so that that activation is also done. This way when someone does oc rsh and gets a bash script, the nss_wrapper stuff behaves like it would when application is running and have equivalent environment when debugging.

This is how I described it is better done in:

• http://blog.dscpl.com.au/2015/12/unknown-user-when-running-docker.html

It works better that way.

FWIW. So far my experiments sort of showed that S2I builder wipes out any ENTRYPOINT in the base images. I need to confirm that but can't do so right now due to broken Internet.

[GrahamDumpleton]

Ignore this.

Is me forgetting that oc rsh or oc exec is not the same as docker run in as much as rsh and exec bypass ENTRYPOINT. Only run uses the ENTRYPOINT.

[mnagy]

Does oc rsh not run a bash shell? @mfojtik @bparees?

[bparees]

@mnagy

$ oc help rsh
Open a remote shell session to a container

This command will attempt to start a shell session in the specified pod. It will default to the
first container if none is specified, and will attempt to use '/bin/bash' as the default shell.
You may pass an optional command after the pod name, which will be executed instead of a login
shell. A TTY will be automatically allocated if standard input is interactive - use -t and -T
to override.

Note, some containers may not include a shell - use 'oc exec' if you need to run commands
directly.

[mnagy]

Right. So that means you need to rsh, and then start python in order to get python from SCL

[bparees]

but I thought @mfojtik 's PROMPT_COMMAND magic was supposed to setup the scl enablement for cases like this... @mfojtik ?

[mfojtik]

@bparees my magic is weak if rsh use something else than bash.

[bparees]

@mfojtik I would have assumed it does use bash... but likely via a /bin/sh symlink to /bin/bash, so perhaps that changes the behavior?

this is definitely an issue imho if oc rsh into our images does not scl enable the right thing.

[mfojtik]

@bparees I think PROMPT_COMMAND is taken into account everytime you have interactive shell that does have PS1 set. I need to check what does rsh do, maybe it invokes /bin/sh which is restricted shell that does not support PROMPT_COMMAND. Long term, we should get rid of this 'hack' and have a way to enable SCL everywhere with one simple configuration setting.

[bparees]

seems to work ok for me in the 3.4 image:

$ oc rsh django-ex-1-qenm0
bash-4.2$ python --version
Python 3.4.2

[bparees]

oc exec does not work, unsurprisingly:

$ oc exec django-ex-1-qenm0 "python --version"
exec: "python --version": executable file not found in $PATH
error: error executing remote command: Error executing command in container: Error executing in Docker Container: -1

[bparees]

so nm, i think we're ok here with a known limitation on directly running commands in the container.

[mfojtik]

@bparees because you invoke the binary directly, bypassing bash

[bparees]

yes i know, hence my statement of "unsurprisingly" :)

[mnagy]

We could theoretically change rsh to run the command through bash -c. Not sure if that would have any risks.

[bparees]

among other things it would mean rsh would only work on images w/ bash. or would need special logic to check if bash was present.

[GrahamDumpleton]

Your oc exec wouldn't have worked because you quoted the full command and so it was taking it as the actual executable to run. Use:

oc exec django-ex-1-qenm0 python --version

and it would run and use system Python and not SCL Python.

The oc rsh is effectively equivalent when you give it a command:

oc rsh django-ex-1-qenm0 python --version

The only difference is that oc rsh automatically attaches the tty and stdin.

[bufke]

I ran into a few use cases where scl_enable threw me off.

1. Extending the s2i image and running python/pip results in the wrong version being used. A workaround is /bin/bash -c "python" but it's not immediately clear why this is needed.
2. It makes a lot of sense to me to use docker for local development. IMO it's far easier and more shareable than doing development with s2i images or without docker. It's actually not so hard to reuse/extend the s2i python image and use it like this however the need to explicitly run bash again threw me off initially.

IMO the ability to run commands like a "normal" docker image would make s2i more accessible - especially so for people who are already familiar with Docker.

[mfojtik]

@hhorak fyi.