Merge remote-tracking branch 'k8s/master' into sync-master

Author: mandre

Dockerfile

@@ -106,11 +106,33 @@ CMD ["sh", "-c", "/bin/barbican-kms-plugin --socketpath ${socketpath} --cloud-co
 ##
 ## cinder-csi-plugin
 ##
-FROM --platform=${TARGETPLATFORM} ${DEBIAN_IMAGE} as cinder-csi-plugin
 
-# Install e4fsprogs for format
-RUN clean-install btrfs-progs e2fsprogs mount udev xfsprogs
+# step 1: copy all necessary files from Debian distro to /dest folder
+# all magic heppens in tools/csi-deps.sh
+FROM --platform=${TARGETPLATFORM} ${DEBIAN_IMAGE} as cinder-csi-plugin-utils
 
+RUN clean-install bash rsync mount udev btrfs-progs e2fsprogs xfsprogs
+COPY tools/csi-deps.sh /tools/csi-deps.sh
+RUN /tools/csi-deps.sh
+
+# step 2: check if all necessary files are copied and work properly
+# the build have to finish without errors, but the result image will not be used
+FROM --platform=${TARGETPLATFORM} ${DISTROLESS_IMAGE} as cinder-csi-plugin-utils-check
+
+COPY --from=cinder-csi-plugin-utils /dest /
+COPY --from=cinder-csi-plugin-utils /bin/sh /bin/sh
+COPY tools/csi-deps-check.sh /tools/csi-deps-check.sh
+
+SHELL ["/bin/sh"]
+RUN /tools/csi-deps-check.sh
+
+# step 3: build tiny cinder-csi-plugin image with only necessary files
+FROM --platform=${TARGETPLATFORM} ${DISTROLESS_IMAGE} as cinder-csi-plugin
+
+# Copying csi-deps-check.sh simply ensures that the resulting image has a dependency
+# on cinder-csi-plugin-utils-check and therefore that the check has passed
+COPY --from=cinder-csi-plugin-utils-check /tools/csi-deps-check.sh /bin/csi-deps-check.sh
+COPY --from=cinder-csi-plugin-utils /dest /
 COPY --from=builder /build/cinder-csi-plugin /bin/cinder-csi-plugin
 COPY --from=certs /etc/ssl/certs /etc/ssl/certs
 

Makefile

@@ -36,7 +36,7 @@ VERSION         ?= $(shell git describe --dirty --tags --match='v*')
 GOARCH		:=
 GOFLAGS		:=
 TAGS		:=
-LDFLAGS		:= "-w -s -X 'k8s.io/component-base/version.gitVersion=$(VERSION)'"
+LDFLAGS		:= "-w -s -X 'k8s.io/component-base/version.gitVersion=$(VERSION)' -X 'k8s.io/cloud-provider-openstack/pkg/version.Version=$(VERSION)'"
 GOX_LDFLAGS	:= $(shell echo "$(LDFLAGS) -extldflags \"-static\"")
 REGISTRY	?= registry.k8s.io/provider-os
 IMAGE_OS	?= linux

charts/cinder-csi-plugin/Chart.yaml

@@ -2,7 +2,7 @@ apiVersion: v1
 appVersion: v1.27.1
 description: Cinder CSI Chart for OpenStack
 name: openstack-cinder-csi
-version: 2.28.0-alpha.2
+version: 2.28.0-alpha.3
 home: https://github.com/kubernetes/cloud-provider-openstack
 icon: https://github.com/kubernetes/kubernetes/blob/master/logo/logo.png
 maintainers:

charts/cinder-csi-plugin/values.yaml

@@ -30,7 +30,7 @@ csi:
   resizer:
     image:
       repository: registry.k8s.io/sig-storage/csi-resizer
-      tag: v1.7.0
+      tag: v1.8.0
       pullPolicy: IfNotPresent
     resources: {}
     extraArgs: {}

charts/manila-csi-plugin/Chart.yaml

@@ -2,7 +2,7 @@ apiVersion: v1
 appVersion: v1.27.1
 description: Manila CSI Chart for OpenStack
 name: openstack-manila-csi
-version: 2.28.0-alpha.2
+version: 2.28.0-alpha.3
 home: http://github.com/kubernetes/cloud-provider-openstack
 icon: https://github.com/kubernetes/kubernetes/blob/master/logo/logo.png
 maintainers:

charts/manila-csi-plugin/values.yaml

@@ -92,7 +92,7 @@ controllerplugin:
   resizer:
     image:
       repository: registry.k8s.io/sig-storage/csi-resizer
-      tag: v1.3.0
+      tag: v1.8.0
       pullPolicy: IfNotPresent
     resources: {}
   nodeSelector: {}

charts/openstack-cloud-controller-manager/Chart.yaml

@@ -4,7 +4,7 @@ description: Openstack Cloud Controller Manager Helm Chart
 icon: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-images-prod/openstack-logo/OpenStack-Logo-Vertical.png
 home: https://github.com/kubernetes/cloud-provider-openstack
 name: openstack-cloud-controller-manager
-version: 2.28.0-alpha.3
+version: 2.28.0-alpha.4
 maintainers:
   - name: eumel8
     email: [email protected]

charts/openstack-cloud-controller-manager/templates/daemonset.yaml

@@ -18,13 +18,12 @@ spec:
   template:
     metadata:
       annotations:
-         checksum/config: {{ include "cloudConfig" . | sha256sum }}
-      labels:
-        {{- include "occm.controllermanager.labels" . | nindent 8 }}
-      annotations:
+        checksum/config: {{ include "cloudConfig" . | sha256sum }}
         {{- with .Values.commonAnnotations }}
         {{- toYaml . | nindent 8 }}
         {{- end }}
+      labels:
+        {{- include "occm.controllermanager.labels" . | nindent 8 }}
     spec:
       {{- with .Values.nodeSelector }}
       nodeSelector:

docs/cinder-csi-plugin/using-cinder-csi-plugin.md

@@ -32,7 +32,7 @@ The Cinder CSI Driver is a CSI Specification compliant driver used by Container
 
 ## CSI Compatibility
 
-This plugin is compatible with CSI versions v1.3.0, v1.2.0 , v1.1.0, and v1.0.0
+This plugin is compatible with CSI v1.8.0
 
 ## Downloads
 

docs/manila-csi-plugin/using-manila-csi-plugin.md

@@ -50,6 +50,7 @@ Parameter | Required | Description
 `type` | _yes_ | Manila [share type](https://wiki.openstack.org/wiki/Manila/Concepts#share_type)
 `shareNetworkID` | _no_ | Manila [share network ID](https://wiki.openstack.org/wiki/Manila/Concepts#share_network)
 `availability` | _no_ | Manila availability zone of the provisioned share. If none is provided, the default Manila zone will be used. Note that this parameter is opaque to the CO and does not influence placement of workloads that will consume this share, meaning they may be scheduled onto any node of the cluster. If the specified Manila AZ is not equally accessible from all compute nodes of the cluster, use [Topology-aware dynamic provisioning](#topology-aware-dynamic-provisioning).
+`autoTopology` | _no_ | When set to "true" and the `availability` parameter is empty, the Manila CSI controller will map the Manila availability zone to the target compute node availability zone.
 `appendShareMetadata` | _no_ | Append user-defined metadata to the provisioned share. If not empty, this field must be a string with a valid JSON object. The object must consist of key-value pairs of type string. Example: `"{..., \"key\": \"value\"}"`.
 `cephfs-mounter` | _no_ | Relevant for CephFS Manila shares. Specifies which mounting method to use with the CSI CephFS driver. Available options are `kernel` and `fuse`, defaults to `fuse`. See [CSI CephFS docs](https://github.com/ceph/ceph-csi/blob/csi-v1.0/docs/deploy-cephfs.md#configuration) for further information.
 `cephfs-kernelMountOptions` | _no_ | Relevant for CephFS Manila shares. Specifies mount options for CephFS kernel client. See [CSI CephFS docs](https://github.com/ceph/ceph-csi/blob/csi-v1.0/docs/deploy-cephfs.md#configuration) for further information.
@@ -130,6 +131,35 @@ Storage AZ does not influence
           Shares in zone-a are accessible only from nodes in nova-1 and nova-2.
 ```
 
+In cases when the Manila availability zone must correspond to the Nova
+availability zone, you can set the `autoTopology: "true"` along with the
+`volumeBindingMode: WaitForFirstConsumer` and omit the `availability`
+parameter. By doing so, the share will be provisioned in the target compute
+node availability zone.
+
+```
+                          Auto topology-aware storage class example:
+
+
+           Both Compute and Storage AZs influence the placement of workloads.
+
+        +-----------+                                         +---------------+
+        | Manila AZ |                                         |  Compute AZs  |
+        |   zone-1  |    apiVersion: storage.k8s.io/v1        |     zone-1    |
+        |   zone-2  |    kind: StorageClass                   |     zone-2    |
+        +-----------+    metadata:                            +---------------+
+              |            name: nfs-gold                             |
+              |          provisioner: nfs.manila.csi.openstack.org    |
+              |          parameters:                                  |
+              +---------+  autoTopology: "true"  +--------------------+
+                           ...
+                         volumeBindingMode: WaitForFirstConsumer
+                           ...
+
+Shares for workloads in zone-1 will be created in zone-1 and accessible only from nodes in zone-1.
+Shares for workloads in zone-2 will be created in zone-2 and accessible only from nodes in zone-2.
+```
+
 [Enabling topology awareness in Kubernetes](#enabling-topology-awareness)
 
 ### Runtime configuration file