Description of problem: Link to Document: https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure/1.1/html-single/maintaining_red_hat_hyperconverged_infrastructure/#configuring_synchronization_schedule Section 3.1.3 Step 1 The doc states that after configuring a geo-replication session that you can verify that geo-replication is configured by going to Hosted-Engine/RHV-M for the master node, clicking the "Volumes" tab, and looking at the info column for the geo-replication icon. It states that if the icon is present then a geo-replication session is configured for that volume. But simply going to the "Volumes" tab and viewing the info column will not show you an icon if you have just created the geo-replication session. Version-Release number of selected component (if applicable): RHHI 1.1 RHV-M 4.1.8 How reproducible: Always Steps to Reproduce: 1. Configure geo-replication session for rhhi 2. Bring up Hosted-Engine/RHV-M 3. Select "Volumes" tab 4. View "info" column and look for geo-replication icon Actual results: After creating a new geo-replication session the "info" column is empty. Expected results: In order for the icon to be visible for the new geo-replication session you must navigate to the "Volumes" tab and select the Volume name that you have geo-replicated to. Select "Geo-Replication" sub-tab and click the sync button. Then RHV-M will recognize that a geo-replication session with this volume has been created. Information about the geo-replication session will then be displayed under the "Geo-Replication" sub tab and above, under the "Volumes" tab, you will then see the geo-replication icon appear under the info column. This should be explained in the doc so that the user does not get confused at why the geo-replication session they just created does not appear to be created. Additional info: This could just as well be a bug for RHV-M
CSS Bug Scrub: Hey just wondering if there is any status to report on this?
Laura, RHHI 1.1 content should be updated as per this requirement. Not sure, this also affects RHHI 2.0 content
Thank you for taking the time to review this. Before I can answer I am curious as to what the end of 'create geo-rep session' is. For testing rhhi 1.1 using this doc: https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure/1.1/html-single/maintaining_red_hat_hyperconverged_infrastructure/#configuring_a_geo_replication_session At section 3.1.2 step 1. I am told 1. Create (but do not start) the geo-replication session I am then sent to a link in Gluster docs to create a geo-replication session. https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/administration_guide/sect-Preparing_to_Deploy_Geo-replication#Setting_Up_the_Environment_for_Geo-replication_Session It never says here to not start the geo-replication session since it is just a doc for gluster not for the rhhi solution. By following the rhhi solution I would consider the end of "create geo-rep session" at step 3. "Configure the meta-volume for geo-replication:" I would naturally stop following this document here since the next step is to start geo-replication which I was told not to do. With this thinking if the instructions to "synchronize volume state" which are needed for rhhi were at the bottom of this gluster doc then it would be missed. Or maybe to get to that point the customer would continue through the doc starting geo-rep and what ever else is in between that and the "synchronize volume state" instructions. If you are referring to the end of the maintaining rhhi 1.1 doc (first doc) at the end of 3.1.2 "Configuring a geo-replication session" then I feel like that would be a good place for it, so when you get to step 3.1.3 that verification check would be valid. Although another link to a different page could be confusing here. Sorry for the long winded response I just want to put some context behind how I have been stepping through and interpreting some of these docs. Please get back to me on any of your thoughts about this.
Hi Adam, That makes complete sense. The reason we link to other docs is to avoid duplicating content, so that we don't need to keep both locations up to date. We're working on a system to share content across guides so this is not necessary, but that's not ready yet. For now, I think you're right and this content is better off duplicated.
The content looks good.