[Blueprint servercloud-r-juju-appserver-support] Juju support for application server technologies (Django, JEE, RoR, etc)

[Antonio Rosales]

Blueprint changed by Antonio Rosales:

Whiteboard changed:
  User Stories:
  As a sysop, I want to deploy a web application container on a cloud node.
  
  As a developer, I want to create a Juju charm to deploy my web
  application on any compatible container. Example of compatible
  container: Django app => Django container; JEE .war => servlet container
  (e.g. Apache Tomcat) or JEE app server (e.g. JBoss); JEE .ear or .jar =>
  JEE app server (e.g. JBoss)
  
  As a sysop, I want to deploy a web application onto a compatible
  container node.
  
  As a sysop, I want to define a named data source in a web app node and
  add a relationship to a database node for that data source.
  
  Risks:
  Properly gathering best practices from developer communities, and integrating that knowledge into the framework charm itself.
  
  Test Plans:
- CharmTesting should be leveraged here to exercise a framework charm with traditional workloads, and to specifically repeatedly exercise the individual functions of the framework charm. 
+ CharmTesting should be leveraged here to exercise a framework charm with traditional workloads, and to specifically repeatedly exercise the individual functions of the framework charm.
  
  Framework charm development will need a base set of application charms
  to test the functionality of the framework itself. There could also be
  an “exerciser” framework charm that specifically and exhaustively tests
  each function of the framework (where a ‘normal’ application charm may
  not exercise all the functions or do it repeatedly).
  
- Release Note: 
+ Release Note:
  Release not may not be applicable here, but we should blog about framework charms so folks now they are available to use.
- 
  
  --- Discussion at UDS ---
  
  Why is this important
  - Application servers come before Apps
  - Private/Enterprise apps are more numerous than public apps
  - Deployment needs to be easier/simpler because testing suffers when deployment is difficult
  --- jitsu import/export for above ?
  - Connect named resources to app without app specifically knowing about it
  - Scalability as needed
  
  PaaSish Ubuntu Juju mailing list:
    -https://lists.ubuntu.com/archives/juju/2012-October/001910.html
  
  Improving framework/infrastructure service charms on Juju mailing list:
    -https://lists.ubuntu.com/archives/juju/2012-September/001884.html
  
- List of possible technologies to take into account:
- mediawiki
- Django
- MongoDB
- Postgres
- MySQL
- node.js
- rails/rack-esque
- memcacheD
- varnish
- redis
- rabbit
- Pyramid
- Sensu
- Logstash
- rsyslog
- WordPress
- 
  Possible implementation options (may not be mutually exclusive):
  # App-by-Subordinate
  juju deploy django
  juju deploy myapp # <---- subordinate
  juju add-relation django myapp
  juju deploy mysql app-db-1
  juju add-relation app-db-1 django # <---- relation handled by django via ORM layer
  juju deploy mongodb
  juju add-relation myapp mongodb # <---- relation handled by the app itself
  --
  # App-by-Config
  juju deploy django --set app-src=git://....
  --
  # App-by-Fork
  bzr branch lp:charms/django myapp

-- 
Juju support for application server technologies (Django, JEE, RoR, etc)
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-appserver-support