Skip to content
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.

Sign up for GitHub

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

Jump to bottom

deployment enhancements #29

Merged
merged 7 commits into from
Apr 1, 2019
Merged

deployment enhancements #29

merged 7 commits into from
Apr 1, 2019

Commits on Apr 1, 2019

  1. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    d9a83c2 View commit details
    Browse the repository at this point in the history

  2. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    a584a36 View commit details
    Browse the repository at this point in the history

  3. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    1d8a018 View commit details
    Browse the repository at this point in the history

  4. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    931e8aa View commit details
    Browse the repository at this point in the history

  5. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    41522f4 View commit details
    Browse the repository at this point in the history

  6. 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.
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    879ba77 View commit details
    Browse the repository at this point in the history

  7. 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).
    @pohly
    pohly committed Apr 1, 2019
    Configuration menu
    Copy the full SHA
    bcd0535 View commit details
    Browse the repository at this point in the history