I think maintaning a dns server is not so hard for you guys and it will bring tons of new users to openshift. Please provide dns servers to save us trying ridiculous ways to use both www and non-www version of our domains.

Right now you can deploy play framework applications to openshift generating an exploded war folder, like it's explained in this article and in this tutorial. There are a couple of disadvantages to this approach. Mainly that you cannot take profit of play framework support for asynchronous requests (something that linkedIn engineers found quite valuable). More over, the first time you deploy, it takes quite a lot of time, because of the play libs. The fact is that Play! uses Netty, a non-blocking I/O protocol library built by the JBoss team. It combines non-blocking I/O with an elegant continuation-based programming model to deliver asynchronous processing of requests. So Openshift would be particularly suitable for native play support, and Netty is indeed the deployment option recommended by play developers. Moreover, other PaaS cloud solutions are already provinding native support for Play Framework, like Heroku (they use Jetty, and adapted it to play framework) and Jelastic, which recently added play framework support (it was the most voted features with more than 500 votes). I guess that having Netty among Jboss stack would certainly make things easier... am I right?

Right now you can deploy play framework applications to openshift generating an exploded war folder, like it's explained in this article and in this tutorial. There are a couple of disadvantages to this approach. Mainly that you cannot take profit of play framework support for asynchronous requests (something that linkedIn engineers found quite valuable). More over, the first time you deploy, it takes quite a lot of time, because of the play libs. The fact is that Play! uses Netty, a non-blocking I/O protocol library built by the JBoss team. It combines non-blocking I/O with an elegant continuation-based programming model…

Many pre-written apps depend on having filesystem access. This makes them difficult to adapt for auto-scaling. It would be good if it were possible to create a shared storage area (for example by using a GlusterFS cartridge) to make auto-scaling more simple.

DIY (Do-It-Yourself) cartridge was a great breakthrough on Openshift platform. We are really grateful! Now there is a need to add scale capabilities to applications built on it. It would be really helpful in case of web applications that uses: Play Framework ... and probably many others.

I'd like to be able to define an S3 bucket which will be automatically mounted on the local filesystem for the application. This way writing files under $OPENSHIFT_DATA_DIR/s3/ will write the data directly to Amazon. There are several fuse based s3 implementations so this shouldn't be very hard to implement.

I would like to use the service behind a corporate firewall. I can't connect via SSH. I can use git repositories from github, because github supports the "smart HTTP" mechanism. (https://github.com/blog/642-smart-http-support) This would be a great addition to OpenShift.

I need to know the IP address of my application so that I can use for white-listing for outbound connections. This should be available for each gear of my application (understandably a different one for each). Openshift should ensure that the IP addresses do not change, once I have this feature enabled for my application. This feature will be useful for different payment processing systems, SMPP Gateways, etc.

I would like to run browser-automation web application tests in cloud, preferably based on Selenium http://code.google.com/p/selenium/Selenium Grid http://selenium-grid.seleniumhq.org/. This would allow continuous integration (having tests ran periodically)continuous deployment (having tests as pass criteria) continuous testing (which loads the application to verify continuously it is working correctly). In terms of technology, this could allow use testing mobile devices in the cloud, using Selenium togerther with mobile emulators. The integration with Hudson/Jenkins technology is possible (JBoss QA heavily using it).