Update KEP to reflect volume cloning beta in 1.16 #1147
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
size/XS
|
/assign @msau42 |
j-griffith
force-pushed
the
update_cloning_kep
branch
from
70be9d7 to
cf4680c
Compare
| @@ -130,6 +132,9 @@ Given that the only implementation changes in Kuberenetes is to enable the featu | |||
|
|
|||
| ## Implementation History | |||
|
|
|||
| Update to beta status for 1.16 release | |||
There was a problem hiding this comment.
Since we haven't landed beta yet, let's just update this to say that 1.15 is alpha
There was a problem hiding this comment.
My bad, I thought we needed to update the KEP to indicate our intent to go to beta for 1.16. I'll replace that, and then when 1.16 lands I'll update the Implementation history then.
| @@ -114,6 +114,8 @@ Currently the CSI provisioner already accepts the DataSource field in new provis | |||
|
|
|||
| To emphasize above, this feature will ONLY be available for CSI. This feature wil NOT be added to In-tree plugins or Flex drivers, this is strictly a CSI only feature. | |||
|
|
|||
| It's important to note that we intentionally require that a source PVC be in the same StorageClass as the PVC being created. This is currently required because the StorageClass determintes characteristics for a volume like `fsType`. Performing a clone from an xfs volume to an ext4 volume for example would not be acceptable, given that a storageClass can have unique information, cloning across storage classes is not something we're able to try and determine safely at this time. | |||
There was a problem hiding this comment.
Maybe this would be more visible under non-goals?
There was a problem hiding this comment.
Added a note in "non-goals" with a link, seems like a good fit, let me know what you think.
j-griffith
force-pushed
the
update_cloning_kep
branch
3 times, most recently
from
d6250bd to
9e315e2
Compare
|
Thanks, can you also update the last-updated entry in the top? |
j-griffith
force-pushed
the
update_cloning_kep
branch
from
9e315e2 to
a4e8b18
Compare
Updated, and added the status update there as well, thanks! |
| last-updated: 2019-04-29 | ||
| status: implementable | ||
| last-updated: 2019-07-17 | ||
| status: Alpha |
There was a problem hiding this comment.
don't think alpha is a valid value for status: https://github.com/kubernetes/enhancements/blob/master/keps/YYYYMMDD-kep-template.md
I think leaving it implementable is fine. I'm unsure if we move it to implemented once it's GA?
There was a problem hiding this comment.
Oh, interesting... sorry, that seemed like a "natural" thing. I put it back to implementable
j-griffith
force-pushed
the
update_cloning_kep
branch
from
a4e8b18 to
1d7b8a7
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
| @@ -114,6 +115,8 @@ Currently the CSI provisioner already accepts the DataSource field in new provis | |||
|
|
|||
| To emphasize above, this feature will ONLY be available for CSI. This feature wil NOT be added to In-tree plugins or Flex drivers, this is strictly a CSI only feature. | |||
|
|
|||
| It's important to note that we intentionally require that a source PVC be in the same StorageClass as the PVC being created. This is currently required because the StorageClass determintes characteristics for a volume like `fsType`. Performing a clone from an xfs volume to an ext4 volume for example would not be acceptable, given that a storageClass can have unique information, cloning across storage classes is not something we're able to try and determine safely at this time. | |||
There was a problem hiding this comment.
It's fine for beta, but we should reassess this requirement for GA and consider loosening it: Instead of adding this limitation/validation to k8s, maybe we say it is up to the storage system to decide if it can support the clone. If someone tries to clone and old/new StorageClass don't match, we can leave it up to the storage system to make that decision and fail the CreateVolume call if it wants to?
There was a problem hiding this comment.
@saad-ali Working on update to GA status and was going to move forward with rewording/lifting the StorageClass restriction. This seems reasonable to me (still), just want to make sure no new thoughts here since July on your side.
There was a problem hiding this comment.
I'm not sure we want to lift the StorageClass restriction. We need to very carefully consider the implications given kubernetes/kubernetes#85233
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: j-griffith, msau42, saad-ali 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 |
k8s-ci-robot
added
the
approved
Update KEP to note graduation from Alpha to Beta for sig-storage cloning feature in 1.16. Also add a note regarding the storageClass restrictions on cloning.
issue: #989