Update documentation to take care of two default storage classes after NFS Provisioner instalation

[rummens]

I would propose an additional comment regarding the fact that the NFS Provisioner installation can end up in two default storage classes. This causes the Kubeflow installation to fail, it is very obvious but still unexperienced people might appreciate an additional comment.

One can just follow these instruction.

I had to modify the annotation a bit, it was storageclass.beta.kubernetes.io/is-default-class instead of storageclass.kubernetes.io/is-default-class.

I wanted to discuss this first because maybe I am the only one running into this problems or it is specific to AKS (Azure Kubernetes Service)

https://www.kubeflow.org/docs/use-cases/kubeflow-on-multinode-cluster/

[issue-label-bot]

Issue-Label Bot is automatically applying the label improvement/enhancement to this issue, with a confidence of 0.81. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[rummens]

Running on Azure there is even a bigger problem because of this thing I cannot change the default storage class, so I had to change the actual kustomize code before deploying. The documentation should reflect this.

Also I am sure if I used the correct IP address and path in the /etc/exports file and the helm command. Maybe someone could clarfiy which IPs to use, how to the CIDR etc.

[jtfogarty]

/area docs
/priority p2

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.