Feature #37087
add ceph-volume zap <osd-id> <osd-uuid> subcommand
0%
Description
Add subcommand to remove an OSD and its underlying storage. This should work for ceph-disk osds as well as lvm osds.
verify given uuid is either marked destroyed in osdmap, or require a --force flag
find any GPT partitions or LVs associated with a destroyed osd and remove them
zap partition table or PV if we removed the last partition or LV
Related issues
History
#1 Updated by Alfredo Deza over 5 years ago
Why would removing an OSD be something that ceph-volume needs to do?
There is already a ticket for destroying/zapping by OSD ID which should take care of the last two items
#2 Updated by Jan Fajerski over 5 years ago
Alfredo Deza wrote:
Why would removing an OSD be something that ceph-volume needs to do?
This was identified in an orchestrator meeting. This feature will be needed for osd replacement.
There is already a ticket for destroying/zapping by OSD ID which should take care of the last two items
zap looks like it does already most of this indeed. Will take a look at this.
#3 Updated by Alfredo Deza over 5 years ago
I understand that removing an OSD is something that was discussed, I am not clear why the orchestrator can't issue the current commands needed instead of adding another abstraction into ceph-volume.
If the current commands for removing an OSD are not sufficient or are inconvenient, lets solve those?
#4 Updated by Jan Fajerski over 5 years ago
Alfredo Deza wrote:
I understand that removing an OSD is something that was discussed, I am not clear why the orchestrator can't issue the current commands needed instead of adding another abstraction into ceph-volume.
If the current commands for removing an OSD are not sufficient or are inconvenient, lets solve those?
By "zap looks like it does already most of this indeed. Will take a look at this." I meant that I'll check how much of this zap already does and where it might need to be extended.
#5 Updated by Jan Fajerski over 5 years ago
zap looks good for managing lvm based osds. I think we´ll need a subcommand to zap ceph-disk deployed OSDs as well though. Otherwise a replacement will have a fairly narrow scope and nautilus cluster will require much manual attention to replace failed ceph-disk OSDs.
Does it make sense to add a general ceph-volume zap command? This could re-use the lvm zap command in case its an lvm OSD and do the necessary if a ceph-disk OSD is found.
#6 Updated by Alfredo Deza over 5 years ago
Does it make sense to add a general ceph-volume zap command? This could re-use the lvm zap command in case its an lvm OSD and do the necessary > if a ceph-disk OSD is found.
That is a good question. The idea initially was that the first level of sub-commands would be "specific to a device technology", LVM being the first one, "simple" being the following one. Now that we have 'inventory' I start to think that we should nix the constraint, which does bother me as the consistency is out the window :(
The current implementation of `lvm zap` does indeed take care of a bunch of use cases (raw devices as well as LVM) and I am currently working on destroying partitions.
Once I have https://bugzilla.redhat.com/show_bug.cgi?id=1644847 completed, lets revisit this to determine if `zap` can go up a level.
#7 Updated by Jan Fajerski over 3 years ago
- Subject changed from add destroy-osd <osd-id> <osd-uuid> subcommand to add ceph-volume zap <osd-id> <osd-uuid> subcommand
#8 Updated by Jan Fajerski over 3 years ago
- Copied to Feature #47925: add ceph-volume simple zap <osd-id> <osd-uuid> subcommand added
#9 Updated by Jan Fajerski over 3 years ago
- Blocked by Feature #47925: add ceph-volume simple zap <osd-id> <osd-uuid> subcommand added