Title: Storage and Backup for Fault Tolerance Describe the issue: This section of the documentation simply states that NFS should not be used for fault tolerance, (which is correct) however there are situations where one might want this in an enterprise situation. The way this is now it more or less says: "NFS does not support SELinux labels, which means that when you use NFS within an OpenShift node YOU MUST ENSURE THAT USERS HAVE THE APPROPRIATE LEVEL OF ACCESS ON YOUR OWN" --caps for emphasis and warning Suggestions for improvement: However we may have customers who do not care as much about protecting apps from each other (isolation) or care that quotas are followed. In these cases the options should be explained to the customer. IE: Explain to the customer what is / what is not supported if you choose to use NFS for gear backed storage. Explain what you get and what you lose I feel we should explain this so that customers can make informed decisions about their deployments. Additional information: GSS Notes on the topic: https://access.redhat.com/site/solutions/474113
(In reply to Eric Rich from comment #0) > Title: Storage and Backup for Fault Tolerance > > Describe the issue: > > This section of the documentation simply states that NFS should not be used > for fault tolerance, (which is correct) however there are situations where > one might want this in an enterprise situation. > > The way this is now it more or less says: > > "NFS does not support SELinux labels, which means that when you use NFS > within an OpenShift node YOU MUST ENSURE THAT USERS HAVE THE APPROPRIATE > LEVEL OF ACCESS ON YOUR OWN" > --caps for emphasis and warning > > Suggestions for improvement: > > However we may have customers who do not care as much about protecting apps > from each other (isolation) or care that quotas are followed. In these cases > the options should be explained to the customer. > > IE: Explain to the customer what is / what is not supported if you choose to > use NFS for gear backed storage. Explain what you get and what you lose > > I feel we should explain this so that customers can make informed decisions > about their deployments. > > Additional information: > > GSS Notes on the topic: https://access.redhat.com/site/solutions/474113 Hi Eric, You filed this bug against the OSE deployment guide: Storage and Backup for Fault Tolerance, but I cannot find the section you are referring to. https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/1/html/Deployment_Guide/Storage_and_Backup_for_Fault_Tolerance.html Could you have a look again and let me know. Many thanks, Julie
Before we document this someone should make sure that putting gears on NFS works *at all*... I suspect it would fail in the same way gears fail when you try to run with SELinux disabled. It's surely not something we're testing.
(In reply to Luke Meyer from comment #5) > Before we document this someone should make sure that putting gears on NFS > works *at all*... I suspect it would fail in the same way gears fail when > you try to run with SELinux disabled. > > It's surely not something we're testing. Hi Luke, Just want to confirm that NFS is not a recommended method of back up and will not be tested by devs at this stage. If this is the case, I will need to close this bug as a won't fix. Kind regards, Julie
I should distinguish between two different things we're talking about here. One is storage for /var/lib/openshift, i.e. the gear home directories. While I still haven't tried it I can virtually guarantee this will not work, even without SELinux in the picture. And even if it did work... it is not a scenario we are testing or supporting and as such it is unlikely to keep on working. When using non-local storage for /var/lib/openshift, which is a good idea for fault tolerance, the expectation is that a block device will be presented that can be formatted and mounted with the appearance of a local file system, with the network-connected nature of it living at a lower layer than if we were dealing with NFS or GFS2. Examples being Amazon EBS, OpenStack Cinder volumes, etc. That's what the section in question is about. Case 2 in which we mention NFS in connection with gears is when the administrator NFS-mounts something on the node (outside /var/lib/openshift) so that the gears can use it. This is quite possible (though it does require custom SELinux policy to allow), but the context is often an attempt to provide "shared storage" to multiple gears. NFS can certainly be used that way, but there isn't really any good way to keep other gears from accessing storage they shouldn't, or to restrict the storage used by gears on the NFS mount. So customers need to be aware of these issues should they wish to do this. I think Eric may be confusing the two cases a little bit. We do not ever want people using NFS for case one, even if they think they know what they are doing. We do not want to document that use case as it is utterly unsupportable, not to mention probably broken. We might want to talk about case 2 somewhere, but I would nominate a kbase, not docs.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days