Juju Framework Charm for Server Application Technologies
This blueprint aims to extend the Juju subordinate service concept, provide support for a number of application server technologies in two ways: charms for some of the most common application servers and tools to enable users to create charms for their own application to be deployed on top of any compatible application server.
Application server technologies such as Django, JavaEE or Ruby on Rails work in a similar way: an application server provides a runtime and services to a number of applications it hosts, such as access to data sources, configuration options, etc in a way that shields the applications from the underlying topology.
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.
Properly gathering best practices from developer communities, and integrating that knowledge into the framework charm itself.
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).
[OUT OF SCOPE]
Release not may not be applicable here, but we should blog about framework charms so folks now they are available to use.
PaaSish Ubuntu Juju mailing list:
Possible implementation options (may not be mutually exclusive):
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
juju deploy django --set app-src=git://....
bzr branch lp:charms/django myapp
Blockers from Dev Point of View for adoption Juju as a dev platform:
- Lack of ability to work locally hurts adoption.
- Tie in messaging of the dev story with local provider landing.
- sherpa will really help this story too.
- Lack of ability to co-locate hurts dev adoption
- Lack of ability to debug hurts dev adoption
vUDS 1305 Notes: http://
Work items for ubuntu-13.05:
[jorge] Coordinate new tag in the GUI for framework charms: DONE
[jorge] Ask UX to help us out with the name: DONE
[jorge] Neo4j Debian package http://
[jorge] Add framework category to charms then get them in the store as recognized category: INPROGRESS
[jorge] Develop stories for Django: TODO
[jorge] Develop stories for Rails: TODO
[mark-mims] Rename Rack -> Rails in the charm store: TODO
[jorge] Develop stories for Node.js: TODO
[jorge] Develop stories for PHP: TODO
[jorge] Develop stories for Java/JBOSS: TODO
[mark-mims] Develop stories for PLay: http://
[marcoceppi] Framework Stack examples: TODO
[marcoceppi] App Development Best Practice: TODO
[marcoceppi] Integrate Framework charms into GUI Workflow: TODO
[marcoceppi] Community engagement & other framework stories: TODO
[mark-mims] reference rails stack to pimp: TODO
[mark-mims] work with hatch on node.js: TODO
[jorge] Follow up with Patrick and Bruno on Django: TODO