Feature/charm update question, multiple services per node & jetty

[Clint Byrum]

Excerpts from Bruce Edge's message of 2012-09-18 16:34:29 -0700:
> Apologies if this is a dup, got bounced for html content.
> 
> I'm kicking the tires on Juju and saw 2 missing pieces for our needs and
> wanted to see if there was any news on these.
> 
> 1) Multiple services per node. The FAQ,
> https://juju.ubuntu.com/docs/faq.html states that currently only one
> service per machine is supported but that this will change in the future.
> What is the current status on this feature?

You can, in fact, run multiple things per machine. However, one service
must be the "primary", and the others "subordinates". This is to allow
you to run, say, run your PHP web app server and then collectd or newrelic
along side. This means they scale up and down 1:1.

If you really require this functionality, there is a very experimental
set of scripts called 'juju-jitsu' with a sub-command called 'deploy-to'
where you can direct a charm to deploy onto a particular machine. but
this is haphazard and there is no specification for it, so its not
something to rely on without accepting those caveats. To be clear, that
is a hacky preview of what may be available in future versions of juju,
but there are no guarantees.

Can you be more explicit with which services you want to run together
on the same machine, and why? If you are using EC2, the instance types
are pretty flexible, so it always puzzles me why users want to run, say,
MySQL and their app service on the same instance.

> 
> 2) I don't see the jetty app server as an available charm. Is this
> forthcoming or would it require a custom charm?
> 

There is an open debate as to whether extremely flexible things like
jetty should be charms or not. For now, apt-get install it and make use
of it in your charm as needed. If there is something that you want to
share with the other jetty users of the world, it may make more sense
to put that into a PPA as a package which other charms can depend on.

The other option is to create jetty as a subordinate, and then require
that this subordinate be deployed with your app's custom charm. I am not
a fan of this approach, but there are many who seem to have gravitated
to it (see the gunicorn charm as an example).

I think eventually we will have some kind of import/include/extend
keyword in metadata.yaml that will make this a lot more clear.