All of lore.kernel.org
 help / color / mirror / Atom feed
From: Travis Rhoden <trhoden@gmail.com>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: ceph-deploy osd destroy feature
Date: Fri, 2 Jan 2015 16:31:11 -0500	[thread overview]
Message-ID: <CACkq2moPdXgDGCtr-jtd+rxEGT3H_SFnVGruvKqfXDuvU8eagg@mail.gmail.com> (raw)

Hi everyone,

There has been a long-standing request [1] to implement an OSD
"destroy" capability to ceph-deploy.  A community user has submitted a
pull request implementing this feature [2].  While the code needs a
bit of work (there are a few things to work out before it would be
ready to merge), I want to verify that the approach is sound before
diving into it.

As it currently stands, the new feature would do allow for the following:

ceph-deploy osd destroy <host> --osd-id <id>

From that command, ceph-deploy would reach out to the host, do "ceph
osd out", stop the ceph-osd service for the OSD, then finish by doing
"ceph osd crush remove", "ceph auth del", and "ceph osd rm".  Finally,
it would umount the OSD, typically in /var/lib/ceph/osd/...


Does this high-level approach seem sane?  Anything that is missing
when trying to remove an OSD?


There are a few specifics to the current PR that jump out to me as
things to address.  The format of the command is a bit rough, as other
"ceph-deploy osd" commands take a list of [host[:disk[:journal]]] args
to specify a bunch of disks/osds to act on at one.  But this command
only allows one at a time, by virtue of the --osd-id argument.  We
could try to accept [host:disk] and look up the OSD ID from that, or
potentially take [host:ID] as input.

Additionally, what should be done with the OSD's journal during the
destroy process?  Should it be left untouched?

Should there be any additional barriers to performing such a
destructive command?  User confirmation?


 - Travis

[1] http://tracker.ceph.com/issues/3480
[2] https://github.com/ceph/ceph-deploy/pull/254

             reply	other threads:[~2015-01-02 21:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02 21:31 Travis Rhoden [this message]
2015-01-02 22:29 ` ceph-deploy osd destroy feature Loic Dachary
2015-01-04 11:07 ` Wido den Hollander
2015-01-05 17:14   ` Travis Rhoden
2015-01-05 17:27     ` Sage Weil
2015-01-05 17:53       ` Travis Rhoden
2015-01-05 18:18         ` Sage Weil
2015-01-06  0:42           ` Robert LeBlanc
2015-01-06  4:21             ` Wei-Chung Cheng
2015-01-06  5:08               ` Sage Weil
2015-01-06  6:34                 ` Wei-Chung Cheng
2015-01-06 14:28                   ` Sage Weil
2015-01-06 16:19                     ` Travis Rhoden
2015-01-06 16:23                       ` Sage Weil
2015-01-06 16:30                         ` Travis Rhoden
2015-01-07  2:18                           ` Wei-Chung Cheng
2015-01-05 17:32     ` Loic Dachary

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACkq2moPdXgDGCtr-jtd+rxEGT3H_SFnVGruvKqfXDuvU8eagg@mail.gmail.com \
    --to=trhoden@gmail.com \
    --cc=ceph-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.