Bug 1567236 - [GSS][RFE] heketi Node replacement and OCP endpoints
Summary: [GSS][RFE] heketi Node replacement and OCP endpoints
Status: CLOSED DUPLICATE of bug 1660681
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: kubernetes
Version: cns-3.6
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Humble Chirammal
QA Contact: Prasanth
Depends On:
Blocks: 1573420 1622458
TreeView+ depends on / blocked
Reported: 2018-04-13 15:47 UTC by Cal Calhoun
Modified: 2019-06-27 15:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-06-27 15:41:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Cal Calhoun 2018-04-13 15:47:57 UTC
Description of problem:

  Customer's Observation:

  "With heketi it is really easy and dynamic to replace a node (due to a failure or decommission), but we have seen that in Openshift the endpoints of heketi do not change and it can become a problem:

  [root@ocp]# oc get endpoints --all-namespaces
  storage-project		heketi-storage-endpoints,,	54m
  testproject		glusterfs-dynamic-claim1,,	49m

  Now, with heketi-cli you can remove node and add a new node The endpoints will not change automatically in Openshift and you have to manually edit all the endpoints for every PV to reflect this change in heketi topology.

  Thinking in an edge case such as replacing all three gluster nodes, even though everything will work because the glusterfs daemon detect correctly the new volume graph, if the pods (or the entire host) restart, they will not know where the new endpoints are and will never connect to the gluster nodes.

  Is there an easy way to replace the endpoints for all pods in case a node replacement has been performed by heketi-cli?

  Is it possible to add functionality to update the endpoints of the pods in case the heketi topology has changed?"

  Please let me know if I can supply any additional information to assist in this effort.

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