Rename "Projectedresource" to "Share"
Rename `ProjectedResource` kind to `Share` to avoid an API stutter. This renaming makes it clear
to admins that they are sharing a resource that is otherwise protected by namespace boundaries.
Inspired by NFS shares, courtesy of
@@ -23,10 +23,10 @@ replaces:
creation-date: 2020-03-17
-last-updated: 2020-04-17
+last-updated: 2020-08-03
<!-- status: provisional|implementable|implemented|deferred|rejected|withdrawn|replaced -->
-status: provisional
+status: implementable
@@ -167,7 +167,7 @@ An admin creates a new cluster level custom resource for encapsulating the shara
```yaml
-kind: ProjectedResource
+kind: Share
apiVersion: projected-resource.storage.openshift.io/v1
metadata:
name: shared-cool-secret
@@ -190,7 +190,7 @@ rules:
- apiGroups:
- projected-resource.storage.openshift.io
resources:
- - projectedResources
+ - shares
resourceNames:
- shared-cool-secret
verbs:
@@ -204,24 +204,24 @@ So, how does an end user discover and utilize our new CR?
First, a few considerations around discovery:
-- one option for cluster admins is to allow "low level" users to get/list `ProjectedResources`; i.e. `oc get projectedresoureces`;
+- one option for cluster admins is to allow "low level" users to get/list `Shares`; i.e. `oc get shares`;
those users can then discover and use them without further involvement from the cluster admin; i.e. the RBAC example above
is applied to those "low level" users
- if this is not acceptable, then some sort of exchange needs to occur between the user and cluster admin
- that exchange results in either cluster admin providing "just enough" information to the user to update their objects so
-the underlying, associated Pod references CSI volumes using `ProjectedResources`
-- or the cluster admin modifies the user's object(s) so they get their `ProjectedResources`
+the underlying, associated Pod references CSI volumes using `Shares`
+- or the cluster admin modifies the user's object(s) so they get their `Shares`
-Second, a few considerations around how we update objects, so they "get" `ProjectedResources` associated with them:
+Second, a few considerations around how we update objects, so they "get" `Shares` associated with them:
- Pod objects themselves, or any API object that exposes the Pod's `volumes` array as part of providing an API that is
converted by a controller into a Pod, can directly add a volume of the CSI type with the correct metadata in the volumeAttributes, a la
```yaml
csi:
- driver: projectedresources.storage.openshift.io
+ driver: projected-resources.storage.openshift.io
volumeAttributes:
- projectedResourceName: the-projected-resource
+ share: the-projected-resource
```
