Bug 1590391

Summary: Describe refresh intervals, default values and visible consequences for the user
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Martin Bukatovic <mbukatov>
Component: doc-RHGS_Web_AdministrationAssignee: Rakesh <rghatvis>
Status: CLOSED CURRENTRELEASE QA Contact: Martin Bukatovic <mbukatov>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rhgs-3.4CC: apaladug, asriram, ebondare, mbukatov, nthomas, rghatvis, rhs-bugs, sankarshan, shtripat
Target Milestone: ---   
Target Release: RHGS 3.4.0   
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: 2018-09-10 15:44:30 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:    
Bug Blocks: 1503142, 1590317    

Description Martin Bukatovic 2018-06-12 14:31:47 UTC 
Description of problem
======================

BZ 1589321 states:

> When cluster is unmanaged then it takes several seconds before it is listed in
> get cluster API call and available to import again.

During discussion ("RHGS-3.4.0 In-flight bug triage" meeting on 2018-06-12)
about this problem, it turned out we need to document what are refresh intervals,
it's default values and few examples of user visible effects (one mentioned in
the BZ mentioned above would be good enough).

Neha in https://bugzilla.redhat.com/show_bug.cgi?id=1589321#c1 provided some
details:

> UI is polling the cluster list API call after every 10 seconds. Hence, the
> updated data will be reflected in UI by maximum 10 seconds if the backend/API
> already contains the updated data.
Comment 1 Martin Bukatovic 2018-06-12 14:43:34 UTC 
Some technical details are missing, and will be provided as an answer to
https://bugzilla.redhat.com/show_bug.cgi?id=1589321#c3
Comment 7 Martin Bukatovic 2018-08-07 09:23:24 UTC 
Acking based on detailed description provided by Shubhendu in comment 4.
Comment 11 Martin Bukatovic 2018-08-17 15:15:47 UTC 
BobbGt asked me for details, but I'm unable to provide suggestions outright.

I need to think this over and validate my understanding with Shubhendu or
Nishanth before going on. We need to be clear about impact of these intervals,
but to fix it, we need to identify the gap and the right answer *exactly* first.
Comment 12 Martin Bukatovic 2018-08-20 15:36:43 UTC 
See also BZ 1595360 (it slipped through my attention because it's already
closed), where Nishanth states:

> Reboot will not reflect on the UI as the node comes back quickly. TTL for
> nodes is 150 seconds and the status will be reflected in the next sync. So if
> you shutdown the node, you will see that reflected in UI as expected after the
> TTL expires.
Comment 13 Nishanth Thomas 2018-08-27 05:25:09 UTC 
For volumes it is sync_interval(Default is 60) + 450
Comment 20 Martin Bukatovic 2018-08-31 15:33:21 UTC 
Since we have good eng. details for 2 use cases which has important visible
effects for storage administrator, I'm going to verify that these 2 cases has
been documented:

 * import of cluster again, just after unmanage
 * effects of TTL for volumes when Gluster storage nodes are shut down
   or offline

We don't have good end user description for other eng. details related to
sync intervals, nor were other use cases with important consequences for
the user identified during work on this BZ.

Both scenarios has been covered in Monitoring Guide:

 * import after unmanage is described in note in 3.1. "Unmanaging Cluster"
   section (as is noted in comment 8)

 * how TTL for volumes affects WA and dashboard when storage nodes are
   offline is described in "8.3. Volume Level Dashboard" section (my previous
   points about missing unit and value of sync interval has been addressed)