-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement dynamic provisioning (beta) of PersistentVolumes via StorageClass #29006
Conversation
Yay, XXL, I am sorry. Generated code + lot of unit test changes. The actual logic is pretty straightforward though. |
Also, something tells me that |
as expected, e2e tests fail:
|
@kubernetes/sig-storage Throwing this on the 1.4 milestone and also I am going to take a stab at reviewing it but realize with my noobness I should not be one to LGTM. On another note. Jan you are pure liquid awesome. |
I am on PTO for next two weeks, @childsb will cover this PR on my behalf. I hope I did not mess it up too much. |
|
||
// ProvisionerParameters holds the parameters for the provisioner that should | ||
// create volumes of this storage class. | ||
ProvisionerParameters map[string]string `json:"provisionerParameters,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if a provisioner needs secret?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since none of our intree provisioners need secrets right now, I think we should keep that for the second phase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Ceph Volume Plugin needs secrets. We'll need it if we are to add a Ceph
provisioner.
On Tue, Jul 19, 2016 at 10:19 AM, bradley childs notifications@github.com
wrote:
In pkg/apis/extensions/types.go
#29006 (comment)
:
+// StorageClass describes the parameters for a class of storage for
+// which PersistentVolumes can be dynamically provisioned.
+//
+// StorageClasses are non-namespaced; the name of the storage class
+// according to etcd is in ObjectMeta.Name.
+type StorageClass struct {
- unversioned.TypeMeta
json:",inline"
- api.ObjectMeta
json:"metadata,omitempty"
- // ProvisionerType indicates the type of the provisioner.
- ProvisionerType string
json:"provisionerType,omitempty"
- // ProvisionerParameters holds the parameters for the provisioner that should
- // create volumes of this storage class.
- ProvisionerParameters map[string]string
json:"provisionerParameters,omitempty"
Since none of our intree provisioners need secrets right now, I think we
should keep that for the second phase.—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubernetes/pull/29006/files/c28e599c704a45c55eb83426fb761329adcc6ed4#r71359954,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADDZzDn9kq-e3mauq2kRGO8XoLtNsPCaks5qXOsWgaJpZM4JNdmW
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Secret is needed once Azure cloudprovider #28821 is ready and we are going to support dynamic provisioning on Azure. Azure storage service access account and keys should be treated as secret.
cc @colemickens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @rootfs, if you're going to piggy-back on the cloudprovider's auth, you might not need your own Secret, right? Since the cloudprovider's service account could be used to retrieve the storage account keys.
Allowing a secret is more flexible though, you could separate privileges better potentially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you need a secret, the coordinates of the secret should be a parameter to the provisioner. Let me note -- this would be the first case in which we allowed secrets to be referenced from outside their namespace and will need to be thought through from an auth/ACL/permissions perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The provisioner should create the secret needed to use the provisioned PV as a part of provisioning the storage.
If i'm creating a RBD volume the PV will need a secret (generated by the provisioner) to connect. each volume secret may/should be different. I would expect secrets needed as a param to provisioner a much smaller use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree to leave Secrets until we have a concrete case. It is a scary precedent to descend into namespaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ProvisionerParameters" is a mouthful, and I think "Provisioner" adds no value. How about "Parameters" or "Arguments"?
I'll add cinder volume type. |
ProvisionerParameters map[string]string `json:"provisionerParameters,omitempty"` | ||
} | ||
|
||
// ProvisionerType describes the type of a provisioner. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgive my ignorance -- I had thought that we were not going to formalize any provisioner types in the API. Did that change while I was out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with Paul. Let's not. Just strike this and the list
|
||
if zone == "" { | ||
// No zone specified, choose one randomly in the same region as the | ||
// node is running. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just FYI it isn't strictly random. It will spread across the zones, realiably so for PetSets
AWS stuff LGTM. Not sure why we are forcing users to do math for IOPS, but it's fine :-) |
Jan & Brad, We have not been updating kubernetes/enhancements#36 :( Reviewed 7 of 8 files at r11. Comments from Reviewable |
Reviewed 1 of 8 files at r11. examples/experimental/persistent-volume-provisioning/README.md, line 46 [r8] (raw file):
|
+lgtm Review status: all files reviewed at latest revision, 1 unresolved discussion. Comments from Reviewable |
re-titled for relnote. The release not tag says "action required". Can you update teh first comment with notes for cluster admins on what action they need to take (I think none, in which case just change the label) |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
I'll update docs after the freeze... How do we document "beta" features? There needs to be a big exclamation mark somewhere that "beta" annotation will be probably replaced by something else in future. |
IMO, no admin action is needed. Alpha annotation is still working, for Beta it's just any other new feature, i.e. read (non-existing) docs. |
@thockin, and thanks for the review! |
GCE e2e build/test passed for commit bb5d562. |
Automatic merge from submit-queue |
W00t! Nice work @jsafrane and @kubernetes/sig-storage ! |
iops = 100 | ||
} | ||
if iops > 20000 { | ||
iops = 20000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why those numbers are hardcoded? Isn't it better to put constants somewhere?
What if they change in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, they already changed :-)
Filled #31115 with constants + a link to AWS docs.
Automatic merge from submit-queue support Azure data disk volume This is a WIP of supporting azure data disk volume. Will add test and dynamic provisioning support once #29006 is merged replace #25915 fix #23259 @kubernetes/sig-storage @colemickens @brendandburns
…oning Automatic merge from submit-queue Dynamic provisioning for flocker volume plugin Refactor flocker volume plugin * [x] Support provisioning beta (#29006) * [x] Support deletion * [x] Use bind mounts instead of /flocker in containers * [x] support ownership management or SELinux relabeling. * [x] adds volume specification via datasetUUID (this is guranted to be unique) I based my refactor work to replicate pretty much GCE-PD behaviour **Related issues**: #29006 #26908 @jsafrane @mattbates @wallrj @wallnerryan
Automatic merge from submit-queue Implement dynamic provisioning (beta) of PersistentVolumes via StorageClass Implemented according to PR kubernetes#26908. There are several patches in this PR with one huge code regen inside. * Please review the API changes (the first patch) carefully, sometimes I don't know what the code is doing... * `PV.Spec.Class` and `PVC.Spec.Class` is not implemented, use annotation `volume.alpha.kubernetes.io/storage-class` * See e2e test and integration test changes - Kubernetes won't provision a thing without explicit configuration of at least one `StorageClass` instance! * Multiple provisioning volume plugins can coexist together, e.g. HostPath and AWS EBS. This is important for Gluster and RBD provisioners in kubernetes#25026 * Contradicting the proposal, `claim.Selector` and `volume.alpha.kubernetes.io/storage-class` annotation are **not** mutually exclusive. They're both used for matching existing PVs. However, only `volume.alpha.kubernetes.io/storage-class` is used for provisioning, configuration of provisioning with `Selector` is left for (near) future. * Documentation is missing. Can please someone write some while I am out? For now, AWS volume plugin accepts classes with these parameters: ``` kind: StorageClass metadata: name: slow provisionerType: kubernetes.io/aws-ebs provisionerParameters: type: io1 zone: us-east-1d iopsPerGB: 10 ``` * parameters are case-insensitive * `type`: `io1`, `gp2`, `sc1`, `st1`. See AWS docs for details * `iopsPerGB`: only for `io1` volumes. I/O operations per second per GiB. AWS volume plugin multiplies this with size of requested volume to compute IOPS of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see AWS docs). * of course, the plugin will use some defaults when a parameter is omitted in a `StorageClass` instance (`gp2` in the same zone as in 1.3). GCE: ``` apiVersion: extensions/v1beta1 kind: StorageClass metadata: name: slow provisionerType: kubernetes.io/gce-pd provisionerParameters: type: pd-standard zone: us-central1-a ``` * `type`: `pd-standard` or `pd-ssd` * `zone`: GCE zone * of course, the plugin will use some defaults when a parameter is omitted in a `StorageClass` instance (SSD in the same zone as in 1.3 ?). No OpenStack/Cinder yet @kubernetes/sig-storage
Implemented according to PR #26908. There are several patches in this PR with one huge code regen inside.
PV.Spec.Class
andPVC.Spec.Class
is not implemented, use annotationvolume.alpha.kubernetes.io/storage-class
StorageClass
instance!claim.Selector
andvolume.alpha.kubernetes.io/storage-class
annotation are not mutually exclusive. They're both used for matching existing PVs. However, onlyvolume.alpha.kubernetes.io/storage-class
is used for provisioning, configuration of provisioning withSelector
is left for (near) future.For now, AWS volume plugin accepts classes with these parameters:
type
:io1
,gp2
,sc1
,st1
. See AWS docs for detailsiopsPerGB
: only forio1
volumes. I/O operations per second per GiB. AWS volume plugin multiplies this with size of requested volume to compute IOPS of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see AWS docs).StorageClass
instance (gp2
in the same zone as in 1.3).GCE:
type
:pd-standard
orpd-ssd
zone
: GCE zoneStorageClass
instance (SSD in the same zone as in 1.3 ?).No OpenStack/Cinder yet
@kubernetes/sig-storage
This change is