Bug 1322714 - RFE Dynamically provisioned pv should handle the permissions out of the box.
Summary: RFE Dynamically provisioned pv should handle the permissions out of the box.
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Erin Boyd
QA Contact: Jianwei Hou
URL:
Whiteboard:
Depends On:
Blocks: 1267746
TreeView+ depends on / blocked
 
Reported: 2016-03-31 08:04 UTC by Christophe Augello
Modified: 2020-07-16 08:44 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-03 21:57:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Christophe Augello 2016-03-31 08:04:33 UTC
3. What is the nature and description of the request?
	If OSE end user create PVC in project/namespace it should be able to utilize it from application (pod/container) also created in the same project/namespace out of box. Currently is it not the case with dynamically provisioned persistent volumes, in pod log we see "Permission denied" exceptions.

4. Why does the customer need this? (List the business requirements here) 
	This is something what we consider as standard use case for OSE customers.

5. How would the customer like to achieve this? (List the functional requirements here)
	This should be automated within OSE itself.

6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
	a. OSE end user create PVC (with annotations volume.alpha.kubernetes.io/storage-class)
	b. OSE end user create new application that utilize newly created PVC
	c. Application works without exceptions
		c.1. oc logs pod-id
		c.2 oc rsc pod-id  # and we can check that at mount point app created files

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
	> N/A

8. Does the customer have any specific timeline dependencies?
	We would need this until July 2016.

9. Is the sales team involved in this request and do they have any additional input?
	No

10. List any affected packages or components. 
	OSE part responsible for persistent volumes

11. Would the customer be able to assist in testing this functionality if implemented?
	Yes

Comment 1 Steve Watt 2016-05-22 18:44:58 UTC
It looks like you're using the experimental (tech preview) Dynamic Provisioning feature. Does this issue still occur if you just claim against an existing Persistent Volume that was manually created? If so, can you provide a reproducer?

Comment 2 Josep 'Pep' Turro Mauri 2016-05-23 10:24:35 UTC
I believe that this request boils down to this:

  https://bugzilla.redhat.com/show_bug.cgi?id=1318764#c3

i.e. the fsGroup setting in the restricted SCC, which has changed by default in 3.2 and can be manually changed in 3.1: "fsGroup.type=MustRunAs".

Can you confirm that this is the case?

If so, maybe what we need here is to document this a bit better

Comment 3 Steve Watt 2016-05-26 14:09:19 UTC
OK, assigning to Erin Boyd's team to take a look.

Comment 5 Erin Boyd 2016-08-16 17:05:03 UTC
If the previous bug was closed as 'not a bug' that this BZ refers to, can someone please summarize the status of this? Can someone provide concise reconstruction instructions, please

Comment 7 Bradley Childs 2018-01-03 21:57:31 UTC
Closing this bug due to age.


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