Need persistent storage for postgres charms

[Chris Johnston]

So we don't lose data and stuff :-)

 affects ubuntu-ci-services-itself
 tag airline
 assignee cjohnston

[Evan (ev)]

Andy wants this targeted to phase 0, so I've done that. We need to be super careful with this one. There are a lot of moving parts and we need to ensure the charm is using the cinder volume from install time.

[Andy Doan (doanac)]

phase-0 isn't going to happen

[Chris Johnston (cjohnston)]

The current proposed way to do this is to have deploy.py create the volumes, deploy the services, link the volume to the service machine, then do juju set to update the service to where postgres is using the volume

[Evan (ev)]

Moving to uce-0. I think we're going to want this in any prodstack deployment. We only held off because of the risk to the phase 0.5 deadline, which has now passed.

[Evan (ev)]

I wonder if we can do this by:
 1. Calling juju add-machine inside deploy.py
 2. Attaching the nova volume to machine 1 in deploy.py
 3. Having "to: 1" in the .yaml for the postgres charm
 4. Running through deploy.py as usual

I vaguely recall discussing this as an option before. Was there some reason we thought it wouldn't work?

[Andy Doan (doanac)]

On 04/24/2014 04:34 AM, Evan Dandrea wrote:
> I wonder if we can do this by:
> 1. Calling juju add-machine inside deploy.py
> 2. Attaching the nova volume to machine 1 in deploy.py
> 3. Having "to: 1" in the .yaml for the postgres charm
> 4. Running through deploy.py as usual
>
> I vaguely recall discussing this as an option before. Was there some
> reason we thought it wouldn't work?

I was thinking along these lines also. I wonder if it would be a better
use of our time to figure out how to patch these semantics into
juju-deployer directly?

[Vincent Ladeuil (vila)]

The fix (using block-storage-borker and storage charms) landed in revno 732