Bug 1679692

Summary: [Doc] Document workflow for scenario when registry and glusterfs share the same nodes
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: khartsoe <khartsoe>
Component: doc-Container_Native_Storage_with_OpenShiftAssignee: Anjana KD <akrishna>
Status: CLOSED CURRENTRELEASE QA Contact: RamaKasturi <knarra>
Severity: high Docs Contact:
Priority: unspecified    
Version: ocs-3.11CC: akrishna, asriram, bkunal, jarrpa, jmulligan, knarra, madam, pasik, puebele, rdavroni, rhs-bugs, rtalur, storage-doc
Target Milestone: ---Keywords: ZStream
Target Release: OCS 3.11.z Batch Update 4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-04 15:44:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1707789    
Bug Blocks: 1709460    

Description khartsoe@redhat.com 2019-02-21 16:45:54 UTC
Description of problem:

Workflow for scenario when registry and glusterfs share the same nodes is not documented and makes this a "special install":

[Per Rav Davroni - Consulting (rdavroni)
Need to add a working inventory file to support each mode for the installation. Based on my research there are two ways of doing this:

1. glusterfs and glusterfs_registry share same nodes and same volumes ( inventory file changes, a separate storage class is created for each) this must be tested and verified

2. glusgerfs and glusterfs_registry share same nodes but on 2 (two) separate volumes attached to each node, they do not share same volumes 
 
basically we need a working ansible playbook for each case above.]

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

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Jose A. Rivera 2019-02-21 19:28:25 UTC
If I'm understanding the request correctly, neither of these two cases are supported scenarios and can not be supported. Only one Gluster pod may run on any given node, thus it is literally impossible for the glusterfs and glsuterfs_registry clusters to share nodes. Unless I am not interpreting this correctly, please close this BZ.

Comment 4 Michael Adam 2019-02-26 16:43:37 UTC
(In reply to Jose A. Rivera from comment #3)
> If I'm understanding the request correctly, neither of these two cases are
> supported scenarios and can not be supported. Only one Gluster pod may run
> on any given node, thus it is literally impossible for the glusterfs and
> glsuterfs_registry clusters to share nodes. Unless I am not interpreting
> this correctly, please close this BZ.

I agree.
If the description means that the intention is to run two ocs/gluster clusters ("glusterfs" and "glusterfs_registry") in parallel on the same set of nodes, then this is technically not possible (except for very maybe using different host network interfaces, but not sure about this), and it is certainly not supported...

Comment 8 RamaKasturi 2019-04-05 19:28:24 UTC
Hello Anjana,

    I see that this needs to be tested explicitly and cannot be taken in during 3.11.3. However it would be good to have a draft document with steps.

Thanks
kasturi

Comment 21 Anjana KD 2019-10-16 14:11:54 UTC
Hello Kasturi and Talur

Attaching a draft content for review

https://docs.google.com/document/d/1sVDVUqV9axl3tVpg8yFAPeZwE2Dx-nik3GbmVHZtLTY/edit#