Bug 1929136: OpenStack: document Manila share mounting #4803
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
bugzilla/severity-medium
openshift-ci-robot
added
the
bugzilla/valid-bug
|
@Fedosin: This pull request references Bugzilla bug 1929136, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (gcheresh@redhat.com), skipping review request. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Fedosin
changed the title
There was a problem hiding this comment.
This is a bug in the manila operator, imho. It should do this automatically if required.
I'm fine documenting this as a workaround, but I think we need to open an issue against the manila operator to track it. The issue should link to this documentation with a note to remove it when the issue is resolved. Additionally, this PR should contain a link to the issue.
| @@ -0,0 +1,35 @@ | |||
| # Connecting nodes to a dedicated Manila network | |||
|
|
|||
| If you are going to use OpenStack Manila on your cluster, you should be aware that the service usually uses a standalone network for its shares, and by default the installer does not connect nodes to this network. It causes problems with mounting shares on an already deployed cluster, as there is no route to the network: | |||
There was a problem hiding this comment.
the service usually uses a standalone network for its shares
Is it worth enumerating situations where this is not the case?
There was a problem hiding this comment.
Here is the deal. CephFS via NFS back end (Red Hat supplied) will always need this extra network connection. So will some vendor storage back ends. But vendor backends support a mode that we in Maniila call DHSS=True where the NFS server presents itself directly on the tenant network (private network where the manila client resides). In these cases no extra network is required.
@maxwelldb as you can see I don't have a crisp, succinct way to enumerate those situations but maybe you can craft something worth adding here ...
There was a problem hiding this comment.
@mdbooth Are you suggesting that Manila CSI operator should modify the worker VMs to connect to the manila network? Even if it had the information on which network Manila exposes its shares, it doesn't seem to be the responsibility of Manila operator to change the definition of the VMs. More the responsibility of the Machine API Operator, which is what we're documenting here.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mandre, tombarron The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
lgtm
|
@Fedosin: All pull requests linked via external trackers have merged: Bugzilla bug 1929136 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
No description provided.