Canonical Juju

juju destroy-service deletes openstack volumes

Bug #1592887 reported by Jacek Nykis on 2016-06-15

This bug affects 8 people

	Status	Importance	Assigned to	Milestone
Canonical Juju	Fix Released	High	Andrew Wilkins	Canonical Juju 2.3-beta1
juju-core	Won't Fix	Undecided	Unassigned
1.25	Won't Fix	Undecided	Unassigned

Bug Description

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

Tags:

Revision history for this message

Cheryl Jennings (cherylj) wrote on 2016-06-16:

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.

Changed in juju-core:
status:	New → Invalid

Revision history for this message

James Troup (elmo) wrote on 2016-06-16:

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.

Changed in juju-core:
status:	Invalid → New

Revision history for this message

Andrew Wilkins (axwalk) wrote on 2016-06-16:

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?

Revision history for this message

Jacek Nykis (jacekn) wrote on 2016-06-17:

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]

Revision history for this message

Stuart Bishop (stub) wrote on 2016-06-17:

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

Revision history for this message

James Troup (elmo) wrote on 2016-06-19: Re: [Bug 1592887] Re: juju destroy-service deletes openstack volumes

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

Anastasia (anastasia-macmood) on 2016-06-22

Changed in juju-core:
status:	New → Triaged
importance:	Undecided → High

Paul Gear (paulgear) on 2016-07-27

tags:

added: canonical-is

Anastasia (anastasia-macmood) on 2016-08-08

Changed in juju-core:
milestone:	none → 2.0.0

Anastasia (anastasia-macmood) on 2016-08-14

tags:

added: blocker

Anastasia (anastasia-macmood) on 2016-08-15

tags:

removed: blocker

Revision history for this message

Richard Harding (rharding) wrote on 2016-08-16:

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.

Changed in juju-core:
milestone:	2.0.0 → 2.1.0

David Britton (dpb) on 2016-08-19

tags:

added: landscape

Canonical Juju QA Bot (juju-qa-bot) on 2016-08-22

affects:	juju-core → juju
Changed in juju:
milestone:	2.1.0 → none
milestone:	none → 2.1.0

Canonical Juju QA Bot (juju-qa-bot) on 2016-08-23

Changed in juju-core:
importance:	Undecided → Critical
status:	New → Triaged

Katherine Cox-Buday (cox-katherine-e) on 2016-09-01

Changed in juju:
assignee:	nobody → Alexis Bruemmer (alexis-bruemmer)

Anastasia (anastasia-macmood) on 2016-09-01

Changed in juju:
milestone:	2.1.0 → 2.0-beta18

Anastasia (anastasia-macmood) on 2016-09-09

Changed in juju-core:
status:	Triaged → Invalid
importance:	Critical → Undecided

Curtis Hovey (sinzui) on 2016-09-09

Changed in juju:
milestone:	2.0-beta18 → 2.0-beta19

Anastasia (anastasia-macmood) on 2016-09-11

Changed in juju:
milestone:	2.0-beta19 → 2.0-rc1

Richard Harding (rharding) on 2016-09-20

Changed in juju:
milestone:	2.0-rc1 → 2.0-rc2

Alexis Bruemmer (alexis-bruemmer) on 2016-09-23

Changed in juju:
milestone:	2.0-rc2 → 2.1.0

Anastasia (anastasia-macmood) on 2016-10-18

Changed in juju-core:
status:	Invalid → Triaged
importance:	Undecided → Critical

Anastasia (anastasia-macmood) on 2017-01-30

Changed in juju-core:
milestone:	none → 1.25.11

Ryan Beisner (1chb1n) on 2017-01-31

tags:

added: uosci

Revision history for this message

Andrew Wilkins (axwalk) wrote on 2017-02-01:

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.

Changed in juju:
milestone:	2.1.0 → 2.2.0
assignee:	Alexis Bruemmer (alexis-bruemmer) → Andrew Wilkins (axwalk)
status:	Triaged → In Progress

Revision history for this message

Anastasia (anastasia-macmood) wrote on 2017-02-01:

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

Changed in juju-core:
status:	Triaged → Won't Fix
importance:	Critical → Undecided
milestone:	1.25.11 → none

Curtis Hovey (sinzui) on 2017-03-24

Changed in juju:
milestone:	2.2-beta1 → 2.2-beta2

Curtis Hovey (sinzui) on 2017-03-30

Changed in juju:
milestone:	2.2-beta2 → 2.2-beta3

Andrew Wilkins (axwalk) on 2017-03-31

Changed in juju:
milestone:	2.2-beta3 → 2.3-alpha1

Revision history for this message

Anastasia (anastasia-macmood) wrote on 2017-03-31:

#10

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

Ian Booth (wallyworld) on 2017-10-04

Changed in juju:
status:	In Progress → Fix Committed

Andrew Wilkins (axwalk) on 2017-10-09

Changed in juju:
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.