remove-unit doesn't take OSDs down

[James Troup]

I ran 'juju destroy ceph-osd/0' and expected this to take the OSDs on
ceph-osd/0 down and out. It didn't; even when ceph-osd/0 was
completely gone, the OSDs were still up and running.

Given ceph is currently run almost exclusively on bare metal (and
therefor entirely possibly not the last unit on the machine), I think
it would make sense for the charms to not assume the machine hosting
the unit is going away and instead explicitly take down the OSDs. And
perhaps stop them from coming back up again to avoid epic confusion on
reboot?

[James Troup (elmo)]

FAOD this is not unit specific; I just did 'juju destroy-service ceph-osd' and still have a functional ceph cluster.

[James Troup (elmo)]

Additionally, the "tuning" done by newer versions of the charm persists after the unit or service has been destroyed. This seems extremely undesirable.

[James Troup (elmo)]

And the alternatives handling for ceph.conf...

[Chris MacNaughton (chris.macnaughton)]

The ceph charms have no stop hook, meaning that there's no expectation of it removing anything on removal, unfortunately

> On Oct 2, 2016, at 19:25, James Troup <email address hidden> wrote:
>
> And the alternatives handling for ceph.conf...
>
> --
> You received this bug notification because you are a member of OpenStack
> Charmers, which is subscribed to ceph in Juju Charms Collection.
> https://bugs.launchpad.net/bugs/1629679
>
> Title:
> destroy-unit doesn't take OSDs down
>
> Status in ceph package in Juju Charms Collection:
> New
>
> Bug description:
> I ran 'juju destroy ceph-osd/0' and expected this to take the OSDs on
> ceph-osd/0 down and out. It didn't; even when ceph-osd/0 was
> completely gone, the OSDs were still up and running.
>
> Given ceph is currently run almost exclusively on bare metal (and
> therefor entirely possibly not the last unit on the machine), I think
> it would make sense for the charms to not assume the machine hosting
> the unit is going away and instead explicitly take down the OSDs. And
> perhaps stop them from coming back up again to avoid epic confusion on
> reboot?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+source/ceph/+bug/1629679/+subscriptions

[Sandor Zeestraten (szeestraten)]

Is this something that is in the plans for future releases?
If not, could we at least state the expected behaviour more explicitly in the readme of the charms?

[James Page (james-page)]

I'll raise this at the next charms IRC meeting for discussion - I think we should teardown and running services when a unit is destroyed (via its stop hook), ensuring that the machine is clean; we can leave the OSD state on disk (which can be overrwritten during re-deployment if need be).

[Ryan Beisner (1chb1n)]

Circling back to this topic, let's be mindful of our position about not automatically wiping block devices.

[Peter Matulis (petermatulis)]

Changed the title as `destroy-unit` is now `remove-unit`.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "James Page <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-ceph-osd/+/659536
Reason: This review is > 12 weeks without comment, and failed testing the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.