The mechanics of OpenShift deployment are based on Git. For those that don't know, at the highest level Git's model is very similar to Lotus Notes/Domino, in the sense that it is based on replication between databases. You can think of a Git repository and a Notes database as being analogous, and the way you deploy code using Git is similar to the way you deploy code using Notes - you just replicate between the database that has the new code and the target database that has the old code (or no code), thereby bringing the target database up to date. This worked beautifully for Notes and seems to work well for Git too. Unlike Notes, Git cannot store the application data, but unlike Git, Notes cannot reason about version history. Using Git has obvious advantages over something like FTP - it is much more managed, supports version history, and so on. A downside of using Git is setup, and the issue there seems to be mostly security management. When we used Git with Eclipse, we just used the https option, which is simple to set up but requires your userID and password to be stored locally. Git has another way of working, using SSH for managing credentials, and OpenShift seems to really want you to use this option. There is a fairly long, involved and impenetrable setup required for this, involving scary concepts like public and private keys, and various bits of open-source software with incomprehensible user interfaces and unknown operating models. Miraculously, we were able to follow these instructions mechanically and it all seemed to work, but it was a high-anxiety experience for me. My nightmare is that it will stop working at some point and I will be left trying to debug it.
Our next learning experience was with our application itself. We already knew that running Python web applications is quite different from running Java web applications on WebSphere. WebSphere is the platform on which your Java web app runs. In some ways, WebSphere replaces the operating system as the container your application runs in. You can think of your application as being a set of libraries that are loaded by WebSphere. This is the "container" model. Python does not work this way - Python web applications do not run in an application container. Python web applications run directly on the operating system, and instead of having a web application server like WebSphere, you load "web framework" code into your Python application. In websphere, the web app function contains the application, while in python the application contains the web app function.
The little application we had written did everything itself - it included a web server, web application function, and the application itself. When we started exploring OpenShift, we suspected that some of this would be provided by Openshift, and that we would have to adjust, but we did not know what this meant. Surprisingly, it was quite difficult to find out. The reason for this is that the OpenShift documentation likes to assume that you wrote your Python code using one of the popular, elaborate and heavyweight web application frameworks like Django, Zope, Flask and so on, and they provide instructions on how to configure them to work with OpenShift. The frameworks handle but also obscure what the basic model is, which is not what we wanted. If you dig around for a while (longer than you would like) you can find examples of more basic programming in Python for OpenShift. The basic story is as follows:
OpenShift relies on two different standard interfaces. One is WSGI and the other is Python virtual environments. Python virtual environments allow multiple Python applications on the same machine to share a Python interpreter but have independent libraries. WSGI is a standard for an interface between web servers and application code. When I say web servers, I do not mean the sort of extensive high-level web application server function provided by WebSphere - I mean much more basic handling of incoming HTTP requests from clients and returning of responses. This is the function that is provided by OpenShift (perhaps using the Apache mod_wsgi plug-in (http://code.google.com/p/modwsgi/) or something like it, I do not know). In order to implement its end of the WSGI contract, your application has to implement a single two-argument function called "application" that will be called by OpenShift's web servers. OpenShift finds your function if you put it in the WSGI/application.py file, or - more commonly - you import it into that file from wherever you put it in your application. (The complete WSGI specification has more options, but this is what the Openshift examples we found do.)
At this point, Frank and I realized that the way we had implemented our little server was not ideal. We had implemented it using the Python module BaseHTTPServer. We would have done better to implement it using something like wsgiref.simple_server. If we had done this, we would already have had an "application" function, and we would have coded to the WSGI interfaces for requests and responses. It took me several hours (5 or 6?) to convert our server to WSGI (I did some other cleanup I'd been itching to do along the way), although I'm sure a skilled Python programmer would have done it in a fraction of the time. I haven't seen it run on OpenShift yet, but I am optimistic - it runs locally.