Bug 1409237 - Would it be possible to use Ceph exclusive locks instead of Kubernetes' fencing?
Summary: Would it be possible to use Ceph exclusive locks instead of Kubernetes' fencing?
Keywords:
Status: CLOSED DUPLICATE of bug 1365867
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: hchen
QA Contact: Jianwei Hou
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-30 15:02 UTC by Miheer Salunke
Modified: 2017-02-01 15:44 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-01 15:44:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Miheer Salunke 2016-12-30 15:02:10 UTC
Description of problem:

We are still experiencing the problem described in issue #01666500 (Openshift Origin issue #7983).
Whenever a node comes down, we cannot mount Ceph PV images on other nodes until we remove the rbd locks manually.

To work around this, we are wondering if it would be possible to use the 'exclusive-lock' feature of Ceph.
That is, to let Ceph handle the locks and to disable Kubernetes/Openshift fencing.



Version-Release number of selected component (if applicable):

We are using Ceph 2.0 (Jewell) and Openshift v3.2.1


How reproducible:
Whenever a node unexpectedly shuts down.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Miheer Salunke 2016-12-30 15:04:46 UTC
There is actually an upstream kubernetes ticket [1] re: this subject.
The answer is, yes, you can use the RBD exclusive lock feature
assuming kubernetes failover is guaranteed to STONITH the other node
before attempting to migrate the services. The rationale is that
currently, the exclusive lock feature is cooperative -- which means
the lock can transparently transition back and forth between RBD
clients. If the original lock owner is dead (via STONITH or other
proceedure), there is no worry about this lock ping-pong.

[1] https://github.com/kubernetes/kubernetes/issues/33013


We actually have an upstream PR to fix this issue, it missed kubernetes 1.5. 
https://github.com/kubernetes/kubernetes/pull/33660

Comment 4 hchen 2017-02-01 15:44:54 UTC

*** This bug has been marked as a duplicate of bug 1365867 ***


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