All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wido den Hollander <wido@42on.com>
To: Travis Rhoden <trhoden@gmail.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: ceph-deploy osd destroy feature
Date: Sun, 04 Jan 2015 12:07:06 +0100	[thread overview]
Message-ID: <54A91EDA.8080008@42on.com> (raw)
In-Reply-To: <CACkq2moPdXgDGCtr-jtd+rxEGT3H_SFnVGruvKqfXDuvU8eagg@mail.gmail.com>

On 01/02/2015 10:31 PM, Travis Rhoden wrote:
> 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/...
> 

Prior to the unmount, shouldn't it also clean up the 'ready' file to
prevent the OSD from starting after a reboot?

Although it's key has been removed from the cluster it shouldn't matter
that much, but it seems a bit cleaner.

It could even be more destructive, that if you pass --zap-disk to it, it
also runs wipefs or something to clean the whole disk.

> 
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Wido den Hollander
42on B.V.
Ceph trainer and consultant

Phone: +31 (0)20 700 9902
Skype: contact42on

  parent reply	other threads:[~2015-01-04 11:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02 21:31 ceph-deploy osd destroy feature Travis Rhoden
2015-01-02 22:29 ` Loic Dachary
2015-01-04 11:07 ` Wido den Hollander [this message]
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=54A91EDA.8080008@42on.com \
    --to=wido@42on.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=trhoden@gmail.com \
    /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.