Bug 1020016 - [RFE] Detail pros and cons of NFS storage for GEARS [NEEDINFO]
[RFE] Detail pros and cons of NFS storage for GEARS
Status: CLOSED NOTABUG
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation (Show other bugs)
1.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Julie
ecs-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-16 15:17 EDT by Eric Rich
Modified: 2015-07-19 20:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Build: CSProcessor Builder Version 1.12 Build Name: 20635, Deployment Guide-null-1.2 Build Date: 06-08-2013 11:50:11 Topic ID: 20621-491079 [Latest]
Last Closed: 2014-02-23 23:11:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
erich: needinfo? (ccoleman)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 474113 None None None Never

  None (edit)
Description Eric Rich 2013-10-16 15:17:35 EDT
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
Comment 2 Julie 2013-11-26 19:39:11 EST
(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
Comment 5 Luke Meyer 2014-02-07 12:17:54 EST
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.
Comment 6 Julie 2014-02-10 01:28:26 EST
(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
Comment 7 Luke Meyer 2014-02-13 20:35:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.