-
Notifications
You must be signed in to change notification settings - Fork 210
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
deployment enhancements #29
Commits on Apr 1, 2019
-
deploy: allow overriding image registry and tags, use fixed images
They can be overridden for all images or per image by setting env variables, for example: IMAGE_REGISTRY=localhost:9000 \ IMAGE_TAG=canary \ CSI_PROVISIONER_TAG=v1.0.2 \ ./deploy/deploy.sh This is useful for users in air-gapped clusters that host their images in a local repository, for developers and for CI testing. We switched to a release model where tags always refer to the same image, therefore we don't need `imagePullPolicy: Always` anymore. We also don't want it for CI testing when using `canary` images, because then images can be loaded once onto a cluster before a test and are guaranteed to not change in the middle of the test. When using kind with locally build images, `imagePullPolicy: Always` breaks deployment because the side-loaded image gets ignored.
Configuration menu - View commit details
-
Copy full SHA for d9a83c2 - Browse repository at this point
Copy the full SHA d9a83c2View commit details -
deploy: wait until pods are up and snapshotter added the CRD
This is crucial because otherwise creating the snapshotter class can fail (depending on timing). This is also useful because the caller then can be sure that the driver installation has succeeded, without having to know details about the pods that belong to the driver.
Configuration menu - View commit details
-
Copy full SHA for a584a36 - Browse repository at this point
Copy the full SHA a584a36View commit details -
deploy: update example for use with current images
The external-provisioner no longer accepts the --provisioner parameter. While at it, parameters are now the same as in external-attacher (same style, -v=5). Right now it is still possible to use the same deployment for Kubernetes 1.13 and Kubernetes master (aka "latest"). But soon we will have to maintain two different deployments, one for Kubernetes 1.13 and one for Kubernetes 1.14. Moving the deployment script into a sub-directory is a first step towards that. The Kubernetes-CSI CI scripts expect to find directories or symlinks to directories name "kubernetes-x.yy" and uses those when testing against that Kubernetes version. If the same deployment works for multiple Kubernetes releases, then the directory name is the oldest supported Kubernetes release and the symlinks get added once it becomes known that those also work.
Configuration menu - View commit details
-
Copy full SHA for 1d8a018 - Browse repository at this point
Copy the full SHA 1d8a018View commit details -
deploy: more helpful output when kubectl fails
While debugging for PR kubernetes-csi#26 it was useful to see the actual input that was sent to kubectl. It's still not perfect, but that's because line numbers by kubectl refer to individual items, not the entire input, but at least it's something.
Configuration menu - View commit details
-
Copy full SHA for 931e8aa - Browse repository at this point
Copy the full SHA 931e8aaView commit details -
deploy: expose csi.sock outside of the cluster
Tools like csi-sanity and csc have to connect to the CSI driver. This can be achieved by exposing the csi.sock as a TCP service with forwarding handled by socat.
Configuration menu - View commit details
-
Copy full SHA for 41522f4 - Browse repository at this point
Copy the full SHA 41522f4View commit details -
deploy: preliminary example for master and Kubernetes 1.14
The only difference compared to kubernetes-1.13 is in the image versions. We still need two examples, because some CSI driver developers may need the older example for Kubernetes 1.13 if they depend on the alpha features. It's preliminary for Kubernetes 1.14 because the actual images haven't been released yet.
Configuration menu - View commit details
-
Copy full SHA for 879ba77 - Browse repository at this point
Copy the full SHA 879ba77View commit details -
deploy: unify and simplify deployment scripts
Conceptually, each deployment can have its own script. This may become relevant at some point, so the CI looks for the script in the individual directories. But in practice the current two copies of the script were identical. It makes sense to keep only a single copy in a neutral place and use it via symlinks. While at it, the unused CRD installation gets removed. It's definitely not needed for 1.14 (no CRDs) and should not be needed for 1.13 (cluster setup must install them).
Configuration menu - View commit details
-
Copy full SHA for bcd0535 - Browse repository at this point
Copy the full SHA bcd0535View commit details