Bug 1804230

It seems like topics in `openshift/installer/blob/master/docs/user` such as `/ovirt/install_ipi.md` duplicate documentation in `https://github.com/openshift/openshift-docs`. Occasional users get lost and confused by this.

I recommend replacing the content of /install_ipi.md and with a suggestion: "For details on installing OpenShift on oVirt/RHV, to go to https://docs.openshift.com/container-platform/4.4/installing/installing_rhv/installing-rhv-default.html"

Otherwise, consider setting Status to CLOSED > UPSTREAM.

*** Bug 1806935 has been marked as a duplicate of this bug. ***

Hi Roy, when verifying this, I did not really focus on the language point of view since this is upstream doc. However, there are few functional things I think should be fixed before moving to VERIFIED.

1. Link to OpenShift-Metal³ kni-installer points to an old, seemingly deprecated repository.

2. To work with this provider one must supply 2 IPs that are related to any MAC in the virtualization env -> ...2 IPs that are *not* related to any MAC...

3. We tell user to put $DNS_VIP into their /etc/resolv.conf. We can definitely keep it there as a workaround, but I believe that primarily we should tell them to create DNS entries for API_VIP and INGRESS_VIP

4. In minimum requirements, we still say that they should have storage that can do 50 IOPS. However, our testing showed that this is not so easy. I recommend linking this article: https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd

due to capacity constraints we will be revisiting this bug in the upcoming sprint

due to capacity constraints we will be revisiting this bug in the upcoming sprint

Hi Jan,

(In reply to Jan Zmeskal from comment #7)
> Hi Roy, when verifying this, I did not really focus on the language point of
> view since this is upstream doc. However, there are few functional things I
> think should be fixed before moving to VERIFIED.
> 
> 1. Link to OpenShift-Metal³ kni-installer points to an old, seemingly
> deprecated repository.
> 
> 2. To work with this provider one must supply 2 IPs that are related to any
> MAC in the virtualization env -> ...2 IPs that are *not* related to any
> MAC...
> 
> 3. We tell user to put $DNS_VIP into their /etc/resolv.conf. We can
> definitely keep it there as a workaround, but I believe that primarily we
> should tell them to create DNS entries for API_VIP and INGRESS_VIP
> 
> 4. In minimum requirements, we still say that they should have storage that
> can do 50 IOPS. However, our testing showed that this is not so easy. I
> recommend linking this article:
> https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-
> fast-enough-for-etcd


Looks like all your comments are included in the current documentation.
Could you please double check?

Hi Douglas, just to make sure we are both on the same page - I understand this bug as referring to upstream documentation that lives in the GH repo. If you believe all of my suggestions have been implemented, feel free to move this to ON_QA and I'll be sure to check it out.

(In reply to Jan Zmeskal from comment #12)
> Hi Douglas, just to make sure we are both on the same page - I understand
> this bug as referring to upstream documentation that lives in the GH repo.
> If you believe all of my suggestions have been implemented, feel free to
> move this to ON_QA and I'll be sure to check it out.

Douglas not around till November, let's get this moving on in next sprint.

I took a look at https://github.com/openshift/installer/blob/master/docs/user/ovirt/install_ipi.md (notice the master branch in the path) and all of my original objections from comment 7 (with the exception of #3) still persist. Either we must show commitment to maintaining the upstream docs and fix those issues or do what Rolfe suggests in comment 1. I don't mind either way, but one of those things needs to happen before this can be verified.

(In reply to Jan Zmeskal from comment #7)

I addressed 1-3 [1] and left 4 open meanwhile because I prefer the official etcd docs after all, at
least in the developer documentation. 

[1] https://github.com/openshift/installer/pull/4353

I assume this bug can be closed as it should cover the official docs and not the installer repo docs?

It appears from comment 15 that Roy addressed Jan's concerns in comment 7, so moving to ON_QA.

If something still needs to be done, please state clearly what that is. As far as I can see, the concern in comment 0 has been addressed.

as I understand I verified this :
1. Link to OpenShift-Metal³ kni-installer points to an old, seemingly
> deprecated repository.

-> the name of link change to 'Bare Metal IPI Networking Infrastructure' and work fine
> 
> 2. To work with this provider one must supply 2 IPs that are related to any
> MAC in the virtualization env -> ...2 IPs that are *not* related to any
> MAC...

-> change to 'excluded from the MAC range'
> 
> 3. We tell user to put $DNS_VIP into their /etc/resolv.conf. We can
> definitely keep it there as a workaround, but I believe that primarily we
> should tell them to create DNS entries for API_VIP and INGRESS_VIP

-> there is no mention to resolv.conf, only to API_VIP
Name resolution of api_vip from your installing machine The installer must resolve the api_vip during the installation, as it will interact with the API to follow the cluster version progress.

4. In minimum requirements, we still say that they should have storage that
> can do 50 IOPS. However, our testing showed that this is not so easy. I
> recommend linking this article:
> https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-
> fast-enough-for-etcd

-<the link to 50IOPS for the Master VM disks, per ETCD requirement doc is broken

check the link in the latest version and it is working
https://github.com/openshift/installer/blob/master/docs/user/ovirt/install_ipi.md

This has been verified and it appears there's nothing left to do on it. So I'm closing this bug.

If you feel that this is incorrect, please reopen with a comment describing what is still necessary to do to address this.