Images used should include Apache httpd/httpd-devel packages. about s2i-python-container HOT 16 CLOSED

Confirmed that simply adding:

httpd
httpd-devel

to the list of packages to install in the Dockerfile will allow mod_wsgi-express to be installed and then work, allowing Apache/mod_wsgi to be used instead.

Note that #60 had to be fixed first as something about what mod_wsgi package installation does triggers something that updates the nssdb, which leaves it with permissions that cause the chmod in the assemble script to fail and so cause the whole build to fail.

from s2i-python-container.

@GrahamDumpleton we are first looking into making the httpd image more useful in terms of layering so we can easily plug configuration for mod_wsgi into it (and allow users to use Apache/mod_wsgi instead of gunicorn). Also I think we would like to use the httpd image as a base image for other frameworks, like Ruby (passenger), Perl and PHP. @bparees I think we should bump the priority of having extendable httpd image in Trello.

from s2i-python-container.

For mod_wsgi-express there isn't really any point to doing that as the binary mod_wsgi package from SCL isn't used, it is simply pip installed. When using mod_wsgi-express the user doesn't need to do any Apache configuration themselves at all as mod_wsgi-express does it all automatically based on command line options to mod_wsgi-express. This provides the best flexibility and gets away from the old OpenShift 2 way of doing things where the user couldn't change the Apache configuration at all and so usually ended up with an inadequate configuration that didn't suit their specific application.

from s2i-python-container.

FWIW, I personally obviously want to see Apache/mod_wsgi the default again and the whole mod_wsgi-express has been purpose built to a degree to make it easier to deploy Apache/mod_wsgi in Docker. It even has special stuff in it to allow it to be used on OpenShift 2.

In going back to using Apache/mod_wsgi via mod_wsgi-express, one of the things that will be quite easy to achieve is a greater ease of portability of an application from OpenShift 2 to 3. This is because one could prior to starting up mod_wsgi-express detect when legacy wsgi/application and wsgi/static exist and so change the command line options to support the use of these. Thus less work for a user in moving across.

Another thing one could perhaps do is detect if a legacy .openshift/action_hooks directory exists and invoke what hooks one still could do for build and deploy. You would have to perhaps fake up certain legacy environment variables related to OpenShift 2 in case they are being used, but the effort could again make it easier to support better moving applications across.

Overall I prefer the use of the action hooks to having too much magic going on in assemble/run scripts such as detecting use of Django and running collectstatic. Magic is some times good, but for things like that I don't believe it always is and just so they know what is going on, is better to have them opt in.

from s2i-python-container.

FYI, I created this trello card: https://trello.com/c/keOtxxXt/697-add-httpd-s2i-image-as-a-base-for-httpd-images

from s2i-python-container.

@hanzz FYI^

from s2i-python-container.

Just noting that the other main benefit of getting back to having mod_wsgi support is integration with FreeIPA's Apache based SSO strategies: http://www.freeipa.org/page/Web_App_Authentication

from s2i-python-container.

@rhcarvalho I think we should just add the requested packages to the dockerfile for now. I'd rather not keep waiting on the common httpd base image.

from s2i-python-container.

For me this isn't really a priority at this point. I have my own separate Python S2I builder which goes quite a way beyond the default builder functionality, supported WSGI servers etc. I have also started a conversation in the Python community about the community developing their own higher level Python base image for Docker which gives beyond Docker Inc Python base images. Part of that will be S2I support. Anyway, the aim is to draw on the wider expertise of the Python web community to come up with a Docker base image and S2I builder which the community believes better suits there needs, with the community supporting it. This would hopefully garner interest beyond just OpenShift and at least have people using a better base image that is setup properly to not run as root etc. I will be presenting more about my own S2I builder for Python and the idea of a community supported builder at devconf.cz.

from s2i-python-container.

Shouldn't all those improvements and functionalities be merged here? I don't see why "openshift/sti-python" cannot reflect the needs and wishes of the community and a fork be required.

from s2i-python-container.

@rhcarvalho +1

from s2i-python-container.

The benefit of separating upstream builders from integrated builders is similar to the benefit of separating upstream projects from downstream packages - even if the downstream version mostly just tracks the upstream one, it doesn't have to track it directly.

For example, this would mean the downstream builder can potentially incorporate OpenShift specific additions that wouldn't make sense in an image designed to be usable independently of OpenShift. In the other direction, the upstream builder may support language runtime choices or WSGI server options we decide not to support in the downstream one.

from s2i-python-container.

@bparees @rhcarvalho one of the reason is that we won't get python 3.15 (is that right?) anytime soon as we depend on SCL to package that. Another reason is that what @GrahamDumpleton was describing to us means the current builder will not be backward compatible with the changes he wants to make (or community wants). I agree that if there is a fundamental feature we are missing in python image, we should add it, but our changes should be additive not backward incompatible. I don't know how that play with image @GrahamDumpleton has in mind.

from s2i-python-container.

@ncoghlan fair enough, but I so far I don't think we've seen any features that don't make sense for both a generic s2i builder, and the openshift s2i builder. If we reach a point where there are features the community wants in a python s2i builder that we do not want in this image, sure, forking makes sense.

@mfojtik a different image for a different version of python is a completely different topic imho. Yes, that would not go in this repository since it's not SCL as you note, but that's really not what we're primarily discussing here.

If adding the httpd-devel packages creates a backards compatibility problem, I agree we need to think about that more carefully and see if there's a way we can do it that does not introduce that problem. If @GrahamDumpleton indicated the changes are not backwards compatible, I missed it, but I admit to not reading the details of this request in great depth. I expect @rhcarvalho to sort that out :)

from s2i-python-container.

From what I have now heard around timelines for when things would need to be a part of the builder image in order to make it into online preview, if we can get httpd and httpd-dev into the image I will at least gladly accept that much. This is on the basis that it is likely going to be the only change that will be able to be incorporated in the time available. Any other more substantial changes are unlikely to be able to be implemented, reviewed and accepted by what I understand is the cut off.

For the preview the only strategy I can see as being workable, from my perspective of wanting to provide a better and more production capable solution, is if we are still going to push people to use the provided S2I builder base images, is for me personally, or under the umbrella of the evangelists team, to have a separate Git repository with alternate assemble and run scripts which would be pulled in by a user into their own application code through a .sti/bin/assemble override script. I would then recommend people use that as an interim measure when evaluating OpenShift as part of the preview and acknowledge we are working on improvements.

That said, due to issue #87, it will be necessary to also tell people to ignore the RHEL based builder image and use the CentOS based image instead. They would need to do this explicitly, or if openshift/origin#6671 has been fixed in a way to allow project overrides for default S2I builders, which I don't really know if it was even though marked as closed, would be to provide a JSON definition for an image stream which maps python image stream in local project to the CentOS based builder.

So I am going to work on that basis. I am also going to start creating separate issues for all the other problems I have found and changes that would suggest.

As to backward compatibility, part of the problem is where a feature which the builder currently provides is arguably a bad feature and will cause problems and in worst case corruption of a users database. I would argue that a certain feature should be removed and having an environment variable to optionally disable the feature isn't really a solution as likely would be too late at that point as damage would be done. If the stance is that all existing functionality must be preserved, then makes it hard to remove stuff which was a mistake to add.

from s2i-python-container.

#87 should be fixed in time, at a minimum it's already fixed for the python33 image.

#6671 is indeed fixed so you can provide your own image in your project, or at least get warned you have multiple matches (at which point you can specify which match you want in a more specific way)

from s2i-python-container.