Cannot deploy canonical WSGI hello world application. about s2i-python-container HOT 15 CLOSED

@GrahamDumpleton we have to pickup some standard filename for the app, right? We choose app.py to match with OpenShift v2 experience. We can certainly add wsgi.py as well. Will that work for you?

from s2i-python-container.

Not sure you are understanding the issue.

The S2I scripts already detect wsgi.py, but it can only work if gunicorn is installed by the requirements.txt file.

The issue of whether oc new-app auto language detection triggers Python when it finds app.py or wsgi.py is a separate issue. Even if it did detect wsgi.py and automatically use the Python S2I builder, it would still fail without gunicorn.

So it is the lack of a default WSGI server which is the real issue.

If you only care about having something run, rather than whether it is suitable for use, you would use wsgiref module as fallback.

BTW, that wsgi-hello-world repo I reference will actually deploy fine now, but that is because it has .s2i overrides which ignore the default S2I builder scripts and pulls in my from a remote repo and uses them instead.

from s2i-python-container.

Should we detect wsgi.py in assemble and install gunicorn as a requirement?

from s2i-python-container.

@mnagy I would rather not be installing additional dependencies based on filename...

from s2i-python-container.

@GrahamDumpleton what solution for this problem you're suggesting? Should we pre-install gunicorn? Is it sufficient to document what you have to do in order to deploy WSGI app?

from s2i-python-container.

@mfojtik we have logic that detects whether gunicorn is installed here https://github.com/openshift/sti-python/blob/master/2.7/s2i/bin/run#L38 and falling back to Django if not. If we pre-install gunicorn, we should remove it.

from s2i-python-container.

@mnagy Django is a web framework, not a WSGI server. Django only comes into play if someone was actually deploying an application implemented using Django and so it had a manage.py file, allowing the Django application to be run using its built in development server.

That fallback is therefore of no use if people are using Flask, Pyramid, Pylons, some other web framework, or using just a wsgi.py with only dependencies from the Python standard library.

As to a solution, I don't see that there is one as you are hamstrung by the policies over everything having to be packaged in SCL.

Not that it is at all relevant since the approach can't be copied because of the policies in place, in my own S2I scripts (which can now work on top of the default Python S2I builder images by overriding bc.spec.strategy.sourceStrategy.scripts), after pip install is done using the users requirements.txt file, if based on configuration of what the user specified they wanted for a WSGI server, or the default of mod_wsgi if none specified, it will pip install the WSGI server and anything else required if the user hadn't done it themselves in the requirements.txt file.

# See whether WSGI server is actually installed and if it isn't and we
# may require it, then install it. It should already be installed for
# mod_wsgi if using the Docker base images.

if [ "$WARPDRIVE_WSGI_SERVER" = "gunicorn" ]; then
    if ! (python -c "import gunicorn" &>/dev/null); then
        pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir gunicorn
    fi
    if [ "$WARPDRIVE_SERVER_TYPE" = "auto" ]; then
        if ! (python -c "import whitenoise" &>/dev/null); then
            pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir whitenoise
        fi
    fi
fi

if [ "$WARPDRIVE_WSGI_SERVER" = "mod_wsgi" ]; then
    if ! (python -c "import mod_wsgi" &>/dev/null); then
        pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir mod_wsgi
    fi
fi

if [ "$WARPDRIVE_WSGI_SERVER" = "uwsgi" ]; then
    if ! (which uwsgi &>/dev/null); then
        pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir uwsgi
    fi
fi

if [ "$WARPDRIVE_WSGI_SERVER" = "waitress" ]; then
    if ! (python -c "import waitress" &>/dev/null); then
        pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir waitress
    fi
    if [ "$WARPDRIVE_SERVER_TYPE" = "auto" ]; then
        if ! (python -c "import whitenoise" &>/dev/null); then
            pip install $WARPDRIVE_PIP_OPTIONS --no-cache-dir whitenoise
        fi
    fi
fi

In the case of WSGI servers which do not support serving static files, whitenoise is also installed and for those an initial WSGI wrapper script is first import to inject the whitenoise wrapper around the actual WSGI application from the users own WSGI script file, or from Django.

I actually never use the Django development server. No matter which of those WSGI servers was to be used, I extra all the details from the Django project via manage.py and then run it with the more capable WSGI server.

Because I automatically use whitenoise, or setup uwsgi or mod_wsgi for static file handling, I never have the issue where if someone had a Django application and they added gunicorn to requirements.txt their static files could break if they hadn't actually set up their Django project with STATIC_ROOT and whitenoise themselves. That is, I even detect when they haven't set up STATIC_ROOT and step in and manage that all for them through some magic.

So my stuff goes much much further in just making sure things work out of the box but still allow choice of WSGI server when it automatic mode where scripts do stuff for you.

from s2i-python-container.

It is not an acceptable experience that even the simplest WSGI hello world application will not work. It would with OpenShift 2.**

Isn't that because OS2 ran mod_wsgi and you really didn't have a choice of something else unless you ran a DIY gear?

What is the requirement from RedHat on this?

I'm the type that likes choice, and in something like this, if there is no default, then so be it. Examples will show how to use the .STI and requirements.txt features to make whatever WSGI server work

I can understand that with OS2 you used mod_wsgi, but is the audience so vast that we need to cover even those that don't understand the tech?

If you choose to push this, I say pull the logic out of this image and show people with examples how to use the .STI folder overrides (your example is a perfect one).

just my .02, hope this helps.

from s2i-python-container.

You could use other WSGI servers in OpenShift 2 but it was a bit of a pain.

The WSGI server either had to be importable and its start function called from the app.py file, or if command line only, you had to os.exec() from the app.py file, but in doing that you had to use some tricks to preserve the process name else the OpenShift scripts would think it hadn't started. Details of that in:

• http://blog.dscpl.com.au/2015/01/using-alternative-wsgi-servers-with.html

from s2i-python-container.

@GrahamDumpleton

Seems like we need an easier way to specify the WSGI information, and not spend a lot of time in .STI/run.sh to make it guess what you're doing.

J

from s2i-python-container.

In my own scripts I have a default 'auto' mode where I will detect whether you have an app.sh, app.py, wsgi.py, manage.py and setup.py.

For app.sh, just run it. For app.py run it with Python. For wsgi.py host it with default WSGI server. For manage.py, if a Django application (it does actually check it is for Django unlike default S2I builder), it will extract Django application details and host it with default WSGI server. For setup.py, extract module name and use application within that module as WSGI application entry point, hosting it with the default WSGI server.

While still in 'auto' mode, you can override the default WSGI server and say specifically you want to use 'mod_wsgi', 'uwsgi', 'gunicorn' or 'waitress'. I worry about how to map that to above cases without you needing to worry about how to start the WSGI server up yourself.

Finally, you can disable 'auto' mode altogether, and say which of the four WSGI servers with builtin support you want to use. I will still start the WSGI server, but you need to specify all the arguments to them (beyond minimum I supply so things work, such as port to listen on and sending logging to terminal) in a server args file.

So I provide the drop it in and have it work automatically mode, with you still getting your WSGI server choice if you want, or you can take over manual control yourself of what options the WSGI server gets and specify where your WSGI application actually is.

Basically I should be able to cater to everyones tastes or requirements. I even provide a more enhanced action hooks mechanism than what OpenShift 2 provided so that you can hook in to build and deployment. Also have hooks for application setup and migration phases when deploying new version so there is a clean way of running these steps with the correct environment.

So it sings, it dances and it comes with a free set of steak knives as well. :-)

from s2i-python-container.

I like the direction, i'm just worried in making it dance, it will become unmanageable :).

I'm also curious, is there a webserver in the STI-Python Image, or is it just WSGI? I could swear I saw httdp in the apt-get config somewhere

from s2i-python-container.

The base S2I Python image only has Apache httpd installed. It does not have mod_wsgi, nor any other WSGI server. I managed to get Apache httpd (with -devel packages) installed to at least allow the pip installable mod_wsgi to be installed by users. That is, isn't system level package for mod_wsgi, but installed by users into their Python installation.

I am no longer really pushing anything for inclusion in the default as can't see that it will be anything but very basic. That is why I am doing everything separately. So is my problem as far as managing it, but then the intent is to make it available and refined enough that the Python community will see interest in it and so help out with supporting it.

I have actually been working on my stuff for almost two years now as it derives from prior Docker only work, so is quite developed as far as providing a very flexible system which can cater for many use cases, just tweaking things at this point.

from s2i-python-container.

Is this issue still relevant? I can see that a wsgi app uses gunicorn automatically if it is installed as an application dependency in the current Python container.

from s2i-python-container.

Please reopen if this is still relevant.

from s2i-python-container.