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

[Bruce Edge]

Thanks for the detailed response. More inline.

On Wed, Sep 19, 2012 at 3:57 PM, Clint Byrum <clint at ubuntu.com> wrote:
> 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.

That makes a lot of sense when you put it that way, both in terms of
pushing multiple charms to a single target and what you decide to
encompass in a charm.

We have multiple deployment configurations that can be 'run everything
on a single VM', to a bare metal host for every service, depending on
whether it's dev, qa, qa scaling tests, staging or production.
For the dev case we put everything on single VMs, while production
get's a server for each service.
We're looking into an Ubuntu MAAS provisioning option with possible
eventual EC2 migration. Right now everything's manually provisioned,
deployed etc.

Our granularity, in addition to postgresql, memcached and a few other
stapes include a collection of jetty webapps where we deploy one or
more jetty apps on a specific VM based on the expected load of that
configuration. Hence the all-in-one dev environments and the very
distributed production env for the same apps/services.

This gets into my other question about a jetty charm. I suppose it
would be more of a 'jetty app' charm as jetty itself is just a
package. Each jetty webapp has xml config files that indicate what
other nodes are involved in specific environment, eg: postgres host
and other webapp locations/URLs.



>
>>
>> 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.
>

I noticed there is a tomcat charm. Is it embroiled in the same
extremely configurable package debate?


> 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).
>

Going back to the multiple charms/node issue, if I could encapsulate
each jetty webapp as a charm, then the config logic for each webapp
would be embedded in it's charm and if I could specify multiple webapp
charms to run on a specific node, this would be ideal.
Why are you not a fan of this approach? Does it violate some existing
juju best practice? Or is there a better option for handling multiple
related, semi-dependent webapps in this scenario?

Apologies for the sheer number of sidetrack questions.

-Bruce


> I think eventually we will have some kind of import/include/extend
> keyword in metadata.yaml that will make this a lot more clear.
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju