juju destroy-service deletes openstack volumes

[Jacek Nykis]

I am testing juju storage support in openstack and I noticed dangerous default behaviour.

I deployed my service like this:
juju deploy --repository=. --storage metrics=3G local:trusty/charmname

This worked fine and 3GB nova volume was attached to my instance. I wanted to redeploy my service so I run:
juju destroy-service charmname

Which silently wiped my nova volume.

This is IMO dangerous. One of the most important reasons I use nova volumes is that they are persistent so I think juju should prompt user before deleting data.

juju 1.25.5-trusty-amd64

[Cheryl Jennings (cherylj)]

What you're seeing is the expected behavior. Support for disassociating volumes from the lifetime of a service is a potential future enhancement, but it isn't currently implemented.

[James Troup (elmo)]

Sorry, even if it's expected behaviour, it's wrong, dangerous and will inevitably cause data loss for Juju users if it's left this way.

Service (or 'application') and data are two separate things. I asked juju to destroy the service - not the data! And it's called persistent storage for a reason - you generally speaking want it to persist.

[Andrew Wilkins (axwalk)]

James, I certainly see where you and Jacek are coming from. The flip side is that other people may not be aware that they're leaving storage behind, and that's going to cost them.

I think it would be reasonable if we required the user to make a choice when destroying a unit, application, model, or controller:

    juju destroy-unit --destroy-storage|--keep-storage

(flag names plucked out of the air, subject to bikeshedding)

If you want to keep some but not all storage, there would be separate commands to explicitly disassociate storage from a unit/application/model/controller that you would call prior to destroying. If you had any persistent storage remaining and failed to specify one of the flags, you'd get an error telling you to do so. What do you think?

[Jacek Nykis (jacekn)]

Andrew,

Yes those extra flags would solve the problem.
To make user experience even better we could have juju destroy-service and other command prompt user about storage something like:

$ juju destroy-service blah
WARNING: units use persistent storage. Delete persistent storage? [ynQ]

[Stuart Bishop (stub)]

How machines are reaped is specified in environment configuration. Should persistent volumes be the same?

[James Troup (elmo)]

Stuart Bishop <email address hidden> writes:

> How machines are reaped is specified in environment configuration.
> Should persistent volumes be the same?

Sure; as long as the default is to keep them ;-)

--
James

[Richard Harding (rharding)]

In talking with Andrew the issue is that Juju storage wasn't built to support this at this time. Even if we leave the volumes, there's not a mechanism to reuse that storage block on a new/different instance.

We need to add support in storage for this in order for this to work properly as expected in this use case.

[Andrew Wilkins (axwalk)]

We are looking at making storage persistent by default in 2.2. When you destroy an application or unit, the storage will be left behind, and there will be new commands to destroy the storage.

[Anastasia (anastasia-macmood)]

We have no plans to back-port persistent storage to 1.25.x. Marking this bug as Won't Fix for it.

[Anastasia (anastasia-macmood)]

PR against feature branch: https://github.com/juju/juju/pull/7186