Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1358188 - [Doc RFE] heketi-cli should support replacement of a failed node
Summary: [Doc RFE] heketi-cli should support replacement of a failed node
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: doc-Container_Native_Storage_with_OpenShift
Version: rhgs-3.1
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: CNS 3.6
Assignee: Bhavana
QA Contact: krishnaram Karthick
URL:
Whiteboard:
Depends On: 1349875 1472642
Blocks: 1445453
TreeView+ depends on / blocked
 
Reported: 2016-07-20 09:26 UTC by Apeksha
Modified: 2017-11-17 05:20 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1349875
Environment:
Last Closed: 2017-11-17 05:15:38 UTC


Attachments (Terms of Use)

Description Apeksha 2016-07-20 09:26:47 UTC
This bug has to be documented.

+++ This bug was initially created as a clone of Bug #1349875 +++

Description of problem:

heketi-cli currently supports only add and delete of a node. It should also support a cleaner way to replace a failed node as well:

#####
# heketi-cli node -h
Heketi Node Management

Usage:
  heketi-cli node [command]

Available Commands:
  add         Add new node to be managed by Heketi
  delete      Deletes a node from Heketi management
  info        Retreives information about the node
  enable      Allows node to go online
  disable     Disallow usage of a node by placing it offline
#####

Version-Release number of selected component (if applicable):
heketi-templates-2.0.2-3.el7rhgs.x86_64
heketi-client-2.0.2-3.el7rhgs.x86_64

--- Additional comment from Luis Pabón on 2016-06-27 08:59:04 EDT ---

Definitely very important feature.  This is planned for Release 3:

https://github.com/heketi/heketi/issues/161

Comment 2 Bhavana 2016-07-25 09:06:37 UTC
Hi Apeksha,

Since this is more Heketi specific and not paricularly associated with containerization (aplo), I think we can add the info in the Administartion Guide under the Heketi section, instead of the "Deployment Guide for Containerized Red Hat Gluster Storage".

Admin Guide: http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Gluster/job/doc-Red_Hat_Gluster_Storage-3.1.3-Administration_Guide%20%28html-single%29/lastBuild/artifact/tmp/en-US/html-single/index.html#idm139854859328432

Do share your thoughts on this.

Comment 3 Bhavana 2016-09-30 09:22:38 UTC
Dropped an e-mail to Luis:

___________________________________________________________

Hello Luis/Apeksha,

This is regarding the following bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1349875

From the link provided by Luis in the description, I see that it is a enhancement for Heketi to be able to provide a new brick on brick failure.

If this enhancement is already included in Heketi, then can you please share what changes need to be made to the Topology file / or using cli in order to provide a new brick on brick failure.

If this is yet to be included in Heketi then please let us know the target release time frame for this so that we can include this bug for our doc planning for that particular release. 

Thanks,
Bhavana

_______________________________________________________________

Comment 4 Bhavana 2016-09-30 11:40:50 UTC
Based on Luis's comment in bug 1349875, this may or may not make it to 3.4:

https://bugzilla.redhat.com/show_bug.cgi?id=1349875#c2

Comment 18 Bhavana 2017-08-29 04:09:50 UTC
Hi talur,

Am adding the needinfo back to you to understand if I can remove the warning. The last time I spoke to Ashiq, he said that we are waiting for the patch to be merged.

Comment 19 Raghavendra Talur 2017-08-30 07:34:51 UTC
Yes, the warning can be removed in doc as the same is now incorporated in cli command operation.

Comment 21 krishnaram Karthick 2017-09-20 04:48:03 UTC
comment # 1:

The following lines although conveys the message seems to be a little confusing.

 Nodes that have devices added to it cannot be deleted. To delete the node, the devices that are associated with the node have to be deleted. To ensure this, the nodes first need to be disabled and removed. 

can we rephrase this to,

Nodes that have devices added to it cannot be deleted. To delete the node, the devices that are associated with the node have to be deleted. Disabling and removing the node ensures all the underlying devices are removed too. Once the node is removed, all the devices in it can be deleted and finally the node can be deleted.

comment # 2:

Removing nodes moves existing bricks from all the devices in the node to other devices

should be,

Removing nodes moves existing bricks from all the devices in the node to other devices in the cluster.

comment # 3:

The last line is a little confusing.

 At this stage, the bricks are migrated from the failed node. Heketi chooses a suitable device based on the brick allocation algorithm. As a result, there is a possibility that all the bricks might not be migrated to the new added device of new node but be migrated to other devices too. 

can be,

 At this stage, the bricks are migrated from the failed node. Heketi chooses a suitable device based on the brick allocation algorithm. 

Otherwise the steps looks good.

Comment 23 krishnaram Karthick 2017-09-20 13:22:28 UTC
Looks good to me. 

Moving the bug to verified.


Note You need to log in before you can comment on or make changes to this bug.