Charm Needed: Cloud Foundry

We're currently working on this.

Any updates on this issue?

Shang Wu,

We have charms, though it uses PPA packages of CloudFoundry.

I don't know if we have a policy yet for Charm Collection inclusion on that.

Juan, would you update this bug with points and branch links to our current cloud foundry charms, and ppa packages?

Hi:

Here are some pointers on how to get the cloudfoundry charms downloaded and deployed in Ubuntu server and Juju.

The charms are divided into:
- cloudfoundry-server
- cloudfoundry-server-dea
- cf-mysql
- cf-mongodb
- cf-redis

The cloudfoundry-server charm contains all of the necessary components for cloudfoundry and can be deployed as a single unit. This is designed mainly for testing.

cloudfoundry-server-dea, cf-mysql, cf-mongodb and cf-redis are additional cloudfoundry charms designed to scale out the initial cloudfoundry-server charm.

Here is an example on how to download and deploy the cloudfoundry charms:

# Create a folder where to download all of the charms
mkdir -p ~/cloudfoundry/charms/oneiric

# Download all of the necessary charms into that directory
cd ~/cloudfoundry/charms/oneiric
bzr branch lp:~cloudfoundry/cloudfoundry/cloudfoundry-server
bzr branch lp:~cloudfoundry/cloudfoundry/cloudfoundry-server-dea
bzr branch lp:~cloudfoundry/cloudfoundry/cf-mysql
bzr branch lp:~cloudfoundry/cloudfoundry/cf-mongodb
bzr branch lp:~cloudfoundry/cloudfoundry/cf-redis

# Bootstrap Juju
juju bootstrap

# Deploy the charms
cd ~/cloudfoundry/charms
juju deploy --repository=. local:oneiric/cloudfoundry-server
juju deploy --repository=. local:oneiric/cloudfoundry-server-dea
juju deploy --repository=. local:oneiric/cf-mysql
juju deploy --repository=. local:oneiric/cf-mongodb
juju deploy --repository=. local:oneiric/cf-redis

# Connect all of the charms together ( add relations )
juju add-relation cloudfoundry-server cloudfoundry-server-dea
juju add-relation cloufdoundry-server cf-mongodb
juju add-relation cloudfoundry-server cf-mysql
juju add-relation cloudfoundry-server cf-redis

# Expand your deployment
juju add-unit cloudfoundry-server-dea
juju add-unit cf-mysql
juju add-unit cf-mongodb
juju add-unit cf-redis

The above commands should deploy a cloudfoundry environment.

Let me know if there are any questions or issues with this.

-Juan

Juan, thanks for sharing!

I am really confused why there is a need for another mysql charm. Looking through it, I don't see anything that would be incompatible with the current mysql charm's admin relationship. In fact the interface looks identical except that you are passing the IP directly rather than looking it up from the host, which may end up making the charms less portable between providers.

The only other piece I see is the 'vcap'/'nats' bit. Until we have co-lo'd charms, that can just live in the mysql charm and only be turned on when using it with cloudfoundry by splitting the 'cf-server' relation into its own bit.

Hi Clint:

Let me look into it and see how can this be done. Cloudfoundry needs root
access for MySQL. Cloudfoundry then uses it's own code to create DBs and
users. I thought that this was a bad thing to have shared among other
charms.

CloudFoundry takes over the entire database server and manages the
connections by itself. Technically there is nothing stopping me from using
the regular mysql charm but, i thought it was a bad idea to have
CloudFoundry take over the DB server when we wouldn't know what other charms
may be affected by decisions that CloudFoundry server does on it's own.

Thanks,

Juan

On Mon, Oct 24, 2011 at 3:56 AM, Clint Byrum <email address hidden> wrote:

> Juan, thanks for sharing!
>
> I am really confused why there is a need for another mysql charm.
> Looking through it, I don't see anything that would be incompatible with
> the current mysql charm's admin relationship. In fact the interface
> looks identical except that you are passing the IP directly rather than
> looking it up from the host, which may end up making the charms less
> portable between providers.
>
> The only other piece I see is the 'vcap'/'nats' bit. Until we have co-
> lo'd charms, that can just live in the mysql charm and only be turned on
> when using it with cloudfoundry by splitting the 'cf-server' relation
> into its own bit.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/803529
>
> Title:
> Charm Needed: Cloud Foundry
>
> Status in A collection of charms for juju:
> In Progress
>
> Bug description:
> We need a formula for Cloud Foundry.
>
> Here are the criteria for formulas:
> https://ensemble.ubuntu.com/Principia
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charm/+bug/803529/+subscriptions
>
>

Excerpts from Juan L. Negron's message of Mon Oct 24 16:47:35 UTC 2011:
> Hi Clint:
>
> Let me look into it and see how can this be done. Cloudfoundry needs root
> access for MySQL. Cloudfoundry then uses it's own code to create DBs and
> users. I thought that this was a bad thing to have shared among other
> charms.
>
> CloudFoundry takes over the entire database server and manages the
> connections by itself. Technically there is nothing stopping me from using
> the regular mysql charm but, i thought it was a bad idea to have
> CloudFoundry take over the DB server when we wouldn't know what other charms
> may be affected by decisions that CloudFoundry server does on it's own.
>

Right, so there's a db-admin interface that you can relate to the regular
mysql charm, and that is for exactly this type of case, it just gives
you root instead of a service-specific user.

It would be quite incorrect for the admin to relate anything else to
a mysql service that was cloudfoundry managed. I do see where we may
want to provide the ability for a related service to say "this server
is mine" and have all subsequent relations fail (and if any are already
established, fail to acquire this lock).

Still its better to aggregate all of the MySQL knowledge around a single
mysql charm which can turn on/off functionality as needed. The idea here
is that we don't want 10 mysql charms, but 10 modes in the one charm,
with the most common use case being the default mode.

(Hopefully though, we will have colo services soon so we don't have to
 also have 10 monitoring interfaces defined. ;)

Sure:

I'll look into using the regular mysql one.

Thanks,

Juan

On Mon, Oct 24, 2011 at 11:59 AM, Clint Byrum <email address hidden> wrote:

> Excerpts from Juan L. Negron's message of Mon Oct 24 16:47:35 UTC 2011:
> > Hi Clint:
> >
> > Let me look into it and see how can this be done. Cloudfoundry needs
> root
> > access for MySQL. Cloudfoundry then uses it's own code to create DBs and
> > users. I thought that this was a bad thing to have shared among other
> > charms.
> >
> > CloudFoundry takes over the entire database server and manages the
> > connections by itself. Technically there is nothing stopping me from
> using
> > the regular mysql charm but, i thought it was a bad idea to have
> > CloudFoundry take over the DB server when we wouldn't know what other
> charms
> > may be affected by decisions that CloudFoundry server does on it's own.
> >
>
> Right, so there's a db-admin interface that you can relate to the regular
> mysql charm, and that is for exactly this type of case, it just gives
> you root instead of a service-specific user.
>
> It would be quite incorrect for the admin to relate anything else to
> a mysql service that was cloudfoundry managed. I do see where we may
> want to provide the ability for a related service to say "this server
> is mine" and have all subsequent relations fail (and if any are already
> established, fail to acquire this lock).
>
> Still its better to aggregate all of the MySQL knowledge around a single
> mysql charm which can turn on/off functionality as needed. The idea here
> is that we don't want 10 mysql charms, but 10 modes in the one charm,
> with the most common use case being the default mode.
>
> (Hopefully though, we will have colo services soon so we don't have to
> also have 10 monitoring interfaces defined. ;)
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/803529
>
> Title:
> Charm Needed: Cloud Foundry
>
> Status in A collection of charms for juju:
> In Progress
>
> Bug description:
> We need a formula for Cloud Foundry.
>
> Here are the criteria for formulas:
> https://ensemble.ubuntu.com/Principia
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charm/+bug/803529/+subscriptions
>
>

This bug is in the review queue because the author was the last to comment. A non author comment removes this Fix Released bug from the review queue.