Portworx Operator Release Notes
23.10.4
March 19, 2024
Improvements
Issue Number | Issue Description |
---|---|
PWX-36274 | For clusters on ARO, AWS, Azure, GCP, ROSA, ROKS or vSphere with OCP version 4.12 and above, Portworx Operator version 23.10.4 facilitates both the export of metrics to OCP Prometheus and the reading of metrics from it. |
PWX-36198 | Portworx Operator 23.10.4 and Autopilot 1.3.14 enable you to deploy a RedHat Openshift Kubernetes Service (ROKS) cluster on IBM cloud using OCP 4.12 or later versions to view metrics in OpenShift Prometheus. |
Fixes
Portworx by PureStorage has fixed the following issues in this release:
Issue Number | Issue Description |
---|---|
PWX-35477 | Portworx deployments on OpenShift 4.14 and later no longer support the Prometheus deployment packaged with the Portworx Operator. This prevented upgrades for users wishing to upgrade from OCP 4.13.x to 4.14.x. Resolution: You can now disable the Prometheus deployment packaged with the operator and use the OpenShift Prometheus stack for monitoring Portworx metrics, allowing you to upgrade to OpenShift 4.14 and later. This approach requires you to expose Portworx metrics to the OpenShift environment to ensure seamless monitoring integration. |
PWX-35655 | A race condition sometimes deregistered the Portworx CSI driver immediately after initial registration. As a result, Portworx CSI volumes became stuck in the Pending state.Resolution: This race condition and accidental de-registration no longer occurs. This change is applicable to Portworx versions 2.13 and above that have enabled CSI. |
PWX-35008 | When the user disabled Stork component via StorageCluster, kube-scheduler image was not getting removed from the cache. As a consequence, once set, user could not update or override the kube-scheduler image path and/or version tag. Resolution: If the user disables Stork component now, kube-scheduler component is cleanly removed and the user can update or override the kube-scheduler image and/or version tag. |
PWX-35007 | User could not update or override the kube-scheduler and kube-controller-manager image paths or version tags using the px-versions ConfigMap.Resolution: User can now update or override the kube-scheduler and kube-controller-manager image paths or version tags using the px-versions ConfigMap. |
PWX-34360 | The csi-node-driver-registrar container ran inside the portworx pods. During a Kubernetes upgrade, when a node is cordoned, the portworx pod is drained. This de-registered the Portworx CSI driver as the container it was in was removed. Any application pod on that node that had not drained until this point became stuck in the Terminating state.Resolution: The stability and availability of the csi driver during upgrades and maintenance processes is now improved, and the csi-node-driver-registrar container is no longer affected by node draining. This change is applicable to Portworx versions 2.13 and above that have enabled CSI. |
PWX-35282 | Previously, when a Kubernetes node was cordoned, the Portworx pod was automatically deleted but would restart after a brief five-second interval. This behavior was intended to allow applications using Portworx volumes sufficient time to drain properly. Resolution: In this release, when a node is cordoned prior to a drain, the Portworx pod will now be deleted and will not restart for the next five minutes, instead of the previous five seconds. This change is implemented following the movement of the csi-node-driver-registrar to the portworx-api daemonset, rendering the portworx pod unnecessary for this duration. This revised approach ensures more stability and less frequent disruptions in Portworx volumes management during node maintenance. |
23.10.3
February 08, 2024
- The Operator version 23.10.3 is available only on OpenShift OperatorHub. Non-OpenShift customers are advised not to upgrade to this version and should await the release of version 23.10.4, which will be available shortly.
- In order to use Portworx with OpenShift version 4.14, you must use Operator version 23.10.3 and Autopilot version 1.3.13. Visit the Upgrade OpenShift to version 4.14 with Portworx document for information on upgrading OpenShift to version 4.14 with Portworx.
Improvements
Issue Number | Issue Description |
---|---|
PWX-36015 | On fresh installs on OpenShift 4.14+, the Portworx Operator will disable the monitoring.prometheus.enabled flag with a warning event. This is done to prevent users from accidentally enabling the unsupported Portworx managed prometheus deployment. |
Fixes
Portworx by PureStorage has fixed the following issues in this release:
Issue Number | Issue Description |
---|---|
PWX-35477 | Portworx deployments on OpenShift 4.14 and later no longer support the Prometheus deployment packaged with the Portworx Operator. This prevented upgrades for users wishing to upgrade from OCP 4.13.x to 4.14.x. Resolution: You can now disable the Prometheus deployment packaged with the operator and use the OpenShift Prometheus stack for monitoring Portworx metrics, allowing you to upgrade to OpenShift 4.14 and later. This approach requires you to expose Portworx metrics to the OpenShift environment to ensure seamless monitoring integration. |
PWX-35655 | A race condition sometimes deregistered the Portworx CSI driver immediately after initial registration. As a result, Portworx CSI volumes became stuck in the Pending state.Resolution: This race condition and accidental deregistration no longer occurs. This change is applicable to Portworx versions 2.13 and above that have enabled CSI. |
PWX-34360 | The csi-node-driver-registrar container ran inside the portworx pods. During a Kubernetes upgrade, when a node is cordoned, the portworx pod is drained. This deregistered the Portworx CSI driver as the container it was in was removed. Any application pod on that node that had not drained until this point became stuck in the Terminating state.Resolution: The stability and availability of the csi driver during upgrades and maintenance processes is now improved, and the csi-node-driver-registrar container is no longer affected by node draining. This change is applicable to Portworx versions 2.13 and above that have enabled CSI. |
PWX-35282 | Previously, when a Kubernetes node was cordoned, the Portworx pod was automatically deleted but would restart after a brief five-second interval. This behavior was intended to allow applications using Portworx volumes sufficient time to drain properly. Resolution: In this release, when a node is cordoned prior to a drain, the Portworx pod will now be deleted and will not restart for the next five minutes, instead of the previous five seconds. This change is implemented following the movement of the csi-node-driver-registrar to the portworx-api daemonset, rendering the portworx pod unnecessary for this duration. This revised approach ensures more stability and less frequent disruptions in Portworx volumes management during node maintenance. |
23.10.2
January 23, 2024
Portworx Enterprise installation or upgrade is currently not supported on OCP 4.14 and above versions.
Fixes
Portworx by PureStorage has fixed the following issues in this release:
Issue Number | Issue Description |
---|---|
PWX-35255 | The Portworx Operator did not create Autopilot Rule Objects (AROs) for Autopilot rules on clusters with KubeVirt VMs. Resolution: The operator now successfully enables the creation of AROs on clusters with KubeVirt VMs. |
PWX-35206 | Attempting to create a PX-Storev2 cluster with an io2 volume, whether specifying the IOPS or not, failed. Resolution: The operator now successfully creates PX-Storev2 clusters without any failures. |
PWX-35203 | The operator ran pre-flight checks on undesired environments. Resolution: The Operator now only runs pre-flight checks on EKS clusters running Portworx 3.0.0 or above. |
PWX-35016 | Prometheus alerts PXKvdbNodeViewUnhealthy and PXKvdbClusterViewUnhealthy used an incorrect metric label {$labels.node_id} to identify Portworx nodes.Resolution: These alerts now correctly use the appropriate node label to display the Portworx node name in the alert. |
PWX-35004 | Fresh installations overwrote explicitly set Stork and Autopilot images in the StorageCluster with an empty string, requiring users to update the StorageCluster again to correct this. Resolution: The operator now honors user-specified images and updates the StorageCluster status accurately. |
PWX-32111 | Pre-flight checks failed during fresh installations with PX-Security enabled on EKS clusters. Resolution: Pre-flight checks now successfully complete in this environment. |
23.10.1
November 22, 2023
Fixes
Issue Number | Issue Description |
---|---|
PWX-35067 | In certain scenarios, the Portworx Operator incorrectly auto-detected the cloud provider when using the cloud drive feature. This issue occurred when users left the spec.cloudStorage.provider field blank while operating on any of the following environments:
User impact: This issue may have prevented Portworx from starting successfully when it was freshly installed or updated. Resolution: Portworx no longer auto detects cloud providers when the spec.cloudStorage.provider field in the StorageCluster spec is left blank. |
23.10.0
November 7, 2023
In certain scenarios, the Portworx Operator incorrectly auto-detects the cloud provider when using the cloud drive feature. This issue occurs when you leave the spec.cloudStorage.provider
field blank while running Portworx on any of the following environments:
- Bare metal
- RKE2
- vSphere
If you encounter this issue, Portworx fails to start successfully when it is freshly installed or upgraded.
As a workaround, please update the spec.cloudStorage.provider
field in your StorageCluster
spec to the correct value for your deployment. Correct values are:
pure
vsphere
aws
azure
gce
ibm
oracle
csi
Improvements
Issue Number | Issue Description |
---|---|
PWX-32147 | The Portworx Operator now supports the OpenShift dynamic console plugin for air-gapped clusters. |
PWX-31732 | You can now list all pods deployed by the operator using the filter: operator.libopenstorage.org/managed-by=portworx . |
PWX-29299 | You can now install Portworx on Oracle Kubernetes Engine (OKE) clusters using operator Helm charts. |
PWX-25748 | Install Grafana and the associated Portworx dashboards by enabling spec.monitoring.grafana.enabled . |
Fixes
Issue Number | Issue Description |
---|---|
PWX-34239 | In GKE environments, the Portworx Operator encountered PVC provisioning issues due to a missing GKE installation chart file in Helm. Resolution: The portworx.io/is-gke: "true" annotation has been added to the elasticsearch-sc StorageClass spec to resolve this issue. |
PWX-33831 | A cordoned node could leave the Portworx kvdb-api pod in a Failed state, potentially interfering with the node's upgrade or maintenance processes.Resolution: The operator now explicitly checks for kvdb-api pods in a Failed state and cleans them up. |
PWX-31025 | Migrating from a Portworx DaemonSet deployment to an operator deployment sometimes resulted in the system being stuck in an Initializing state, despite the successful completion of the migration.Resolution: The migration process from DaemonSet to Operator deployment has been improved to properly transition states. |
PWX-30455 | While the StorageCluster spec allows adding custom container mounts, it was previously not possible to use the same mounts as the default Portworx installation directories.Resolution: Custom mounts in the StorageCluster spec can now override the default Portworx directories. For instance, directories like /opt/pwx or /var/cores can be changed to different directories on a partition with more disk space. |
Known issues (Errata)
Issue Number | Issue Description |
---|---|
PWX-32111 | PX-Security is not currently supported on PX-Store V2, and the Operator pre-check will not proceed for this combination. |
23.7.0
September 12, 2023
Notes
Enhanced Security: This release addresses security vulnerabilities to enhance overall security.
Tech Preview: The OCP Dynamic Plugin for air-gapped installs is currently in tech preview.
The Portworx Operator fully supports generic HTTP/HTTPS proxies. However, there is limited support for HTTPS proxies using SSL inspection, such as Next-Generation Firewalls that re-encrypt SSL traffic. To accommodate HTTPS proxy with SSL:
Portworx by PureStorage recommends configuring the Portworx StorageCluster, Portworx Operator, and License Server similarly to air-gapped environments.
For the Portworx StorageCluster, you can configure the proxy's self-signed Certification Authority (CA) certificate.
noteTelemetry connection to Pure1 with the Next-Generation Firewall is not supported.
Improvements
Issue Number | Issue Description |
---|---|
PWX-32188 | The Portworx Operator now includes portworx.io/tls-cipher-suites and portworx.io/tls-min-version configuration parameters for the portworx-pvc-controller . These parameters allow for specifying TLS cipher-suites preferences and setting the minimum TLS version, respectively.Note: Due to a Golang limitation, selecting VersionTLS13 disables the customization of TLS cipher-suites. |
PWX-32147 | The operator now enables OCP dynamic plugin installation for air-gapped clusters, including support for custom image registries. Additionally, clusters with PX-Security enabled also support OCP dynamic plugins. |
PWX-32011 | The operator can now utilize the PX_HTTPS_PROXY environment variable to configure the Envoy proxy to use an internal URL to connect to the destination host. |
PWX-30520 | The operator offers enhanced security for JWT package. |
PWX-27765 | The StorageCluster now displays more defined and detailed phases of installation and upgrade, such as initializing , running , degraded , uninstalling , and others, in the condition list. |
Fixes
Issue Number | Issue Description |
---|---|
PWX-32145 | Previously, OCP dynamic plugin images were not included in the px-versions ConfigMap.Resolution: OCP dynamic plugin images are now correctly listed in the ConfigMap. |
PWX-31944 | In air-gapped environments, the csi-ext-pod pod experienced startup failures due to the default inclusion of the csi-health-monitor-controller container.Resolution: The csi-health-monitor-controller container has been disabled to ensure uninterrupted startup of the csi-ext-pod . |
PWX-31915 | Occasionally, a cordoned node could leave the Portworx kvdb-api pod in a Completed state, potentially disrupting the node's upgrade or maintenance processes.Resolution: The Portworx Operator now proactively checks for kvdb-api pods in a Completed state and removes any terminated pods to prevent interference. |
PWX-31842 | On the PKS platform, restarting Portworx pods and services led to excessive mounts, slowed IO operations, and, in some cases, caused the host to become unresponsive. Resolution: Users should upgrade the Portworx Operator to version 23.7.x and reboot affected PKS nodes to resolve these issues. |
23.5.1
July 11, 2023
Fixes
Issue Number | Issue Description |
---|---|
PWX-32051 | The port used for telemetry could be configured as an NFS port in certain distributions, leading to conflicts. Resolution: The Portworx Operator now uses port 9029 for telemetry in Portworx 3.0.0 and later versions to avoid this issue. |
PWX-32073 | The CSI provisioner was issuing multiple requests for PVC provisioning, causing system delays. Resolution: The CSI provisioner timeout has been updated to mitigate these delays. |
PWX-32197 | In proxied Envoy versions greater than 1.22, a necessary configuration section was missing, preventing telemetry pods from starting. Resolution: The configuration section for Envoy running with an HTTP proxy has been added, ensuring telemetry pods start as expected. |
23.5.0
June 13, 2023
Notes
The PodSecurityPolicy
resource is deprecated from Kubernetes 1.21 and unsupported from 1.25.x. Hence, you need to use either Pod Security Admission or third-party admission-plugin or both to impose restrictions on pods.
New features
Portworx by Pure Storage is proud to introduce the following new features:- OpenShift users on OCP 4.12 and higher versions can now enable the Console plugin option during Portworx Operator installation or upgrade to use the Portworx Cluster dashboard within the OpenShift UI to manage their Portworx cluster. This avoids switching and navigating between different management interfaces to perform Day 2 operations.
- The Portworx Operator now supports loading installation images into multiple custom registries for seamless Portworx installation for all Kubernetes installation environments (air gapped and non-air gapped). You need to update the path of the custom registry for each of these components in the version manifest prior to installation. For more information, see Install Portworx on Kubernetes with a custom container registry.
Improvements
Improvement Number | Improvement Description |
---|---|
PWX-26156 | If your Portworx runs on Kubernetes version 1.26 and higher, the Portworx Operator auto-enables CSI in StorageCluster for both fresh installation and upgrade to ease volume migration. |
PWX-27920 | the operator enables batching in metrics collector to reduce memory usage on large scale clusters. |
Fixes
Issue Number | Issue Description |
---|---|
PWX-28650 | The Portworx Operator used to allow Autopilot to access all resources on the cluster without any restrictions. Resolution: The operator now enables Autopilot to provide selective access for the required resources (actions), thus minimizing the RBAC permissions. |
PWX-30386 | StorageCluster warnings were issued when the operator tried to delete a non-existent component. Resolution: Warning alerts are no longer issues in such scenarios now. |
PWX-30737 | Stork scheduler pods were not created and px-csi-ext pods were stuck in a pending state. Resolution: Update Stork scheduler ClusterRole to use Portworx SCC to create a Stork scheduler pod. |
PWX-30943 | Prometheus pod crashed due to out of memory issue with default memory and CPU. Resolution: Users can now control and enforce memory usage on their actual cluster deployment and set the required limit by editing the StorageCluster spec. |
PWX-31551 | The latest OpenShift installations have introduced more restrictive SELinux policies, as a result, non-privileged pods cannot access the csi.sock CSI interface file.Resolution: All Portworx CSI pods now run as privileged pods. |
Known issues (Errata)
Issue Number | Issue Description |
---|---|
PD-2156 | On OpenShift clusters running with Dynatrace, Portworx might not start after upgrading OCP version from 4.11 to 4.12 Workaround: Delete the Portworx pod on the node. |
23.4.1
September 1, 2023
Fixes
Issue Number | Issue Description |
---|---|
PWX-32073 | During PVC provisioning, CSI CreateVolume function used to constantly retry volume creation causing CSI provisioner to become unresponsive leading to delays.Resolution: CSI provisioner timeout value is updated from 10 seconds to 5 minutes to provide adequate time for volume creation. |
23.4.0
May 03, 2023
Improvements
Improvement Number | Improvement Description |
---|---|
PWX-27168 | A new annotation is added to the Portworx Operator to let users customize Prometheus alert rules without the operator rolling back the change. Add the following annotations in the Prometheus spec to customize the alerts:metadata: annotations: operator.libopenstorage.org/reconcile: "0" |
PWX-24897 | You can configure Prometheus with these new flags in your StorageCluster spec for monitoring Portworx:
|
Fixes
Issue Number | Issue Description |
---|---|
PWX-29409 | In a cluster, if there was a zone with no nodes available for Portworx, Operator failed to pick a default value for the MaxStorageNodesPerZone parameter.Resolution: Operator now ignores zone(s) with no nodes and utilizes other nodes to calculate MaxStorageNodesPerZone parameter value. |
PWX-29398 | Operator triggered nil panic error if no nodes were available to install Portworx.Resolution: User interface displays an appropriate error message instead of panicking when there are no nodes available for Portworx installation. |
23.3.1
March 29, 2023
Improvements
Improvement Number | Improvement Description |
---|---|
PWX-30005 | Improvement for air-gapped clusters: the Portworx Operator now checks for Pure1 connectivity when enabled for the first time. If a telemetry cert has not yet been created and Portworx cannot reach Pure1, the operator disables telemetry. |
23.3.0
March 22, 2023
Notes
- Starting with 23.3.0, the naming scheme for Operator releases has changed. Release numbers are now based on the year and month of the release.
- You must upgrade to Operator 23.3.0 to avoid an
ImagePullError
after April 3rd due to changes in the Kubernetes registry path. Kubernetes is freezinggcr.k8s.io
and moving to theregistry.k8s.io
repository on 3rd of April. For more information, see the Kubernetes blog.
New features
Portworx by Pure Storage is proud to introduce the following new features:telemetry is now enabled by default.
- On fresh installations, all clusters will have telemetry enabled when you generate a spec from PX-Central.
- When you upgrade the Portworx Operator to version 23.3.0, telemetry will be enabled by default unless you disable telemetry in the StorageCluster spec, or when the
PX_HTTPS_PROXY
variable is configured.noteFor air-gapped clusters, you must disable telemetry explicitly during spec generation. To learn how to disable telemetry, see the air-gapped installation section. If you do not disable telemetry, telemetry pods will remain in the
init
state as Portworx fails to reach the Pure1 telemetry endpoint. This does not impact Portworx pods.
The StorageCluster spec for configuring Prometheus now contains the following new fields:
spec.Monitoring.Prometheus.Resources
: Provides the ability to configure Prometheus resource usage, such as memory and CPU usage. If the resources field is not configured, default limits will be set to CPU 1, memory 800M, and ephemeral storage 5G.spec.Monitoring.Prometheus.securityContext.runAsNonRootin
: Provides the ability to configure the Prometheus service type, and the default value is set totrue
.
Added a new environment variable
KUBELET_DIR
. This variable can be used to specify a customkubelet
directory path.Added an annotation
portworx.io/scc-priority
to the StorageCluster spec for configuring the priority of Portworx security context constraints (SCC).
Improvements
Improvement Number | Improvement Description |
---|---|
PWX-28147 | When upgrading to Operator version 23.3.0, all CSI sidecar images will be updated to the latest versions. |
PWX-28077 | Operator will now update Prometheus and Alertmanager CRDs. |
Fixes
Issue Number | Issue Description |
---|---|
PWX-28343 | During Portworx Operator upgrade, the old telemetry registration pod were not being deleted. Resolution: Changed the update deployment strategy of px-telemetry-registration to Recreate . Now the old pods will be deleted before the new ones are created. |
PWX-29531 | The prometheus-px-prometheus pods were not being created in OpenShift due to failed SCC validation.Resolution: The prometheus-px-prometheus pods are now being created in OpenShift environments. |
PWX-29565 | Upgrading OpenShift from version 4.11.x to 4.12.3 was failing for the Portworx cluster. Resolution: Changed Portworx SCC default priority to nil . |
PWX-28101 | If the kubelet path was not set to the default path, the CSI driver would fail to start, and the PVC could not be provisioned.Resolution: Now the KUBELET_DIR environment variable can be used to specify a custom path for the CSI driver. |
1.10.5
March 07, 2023
Updates
- Added the new
spec.updatestrategy.rollingupdate.minreadyseconds
flag. During rolling updates, this flag will wait for all pods to be ready for at leastminReadySeconds
before updating the next batch of pods, where the size of the pod batch is specified through thespec.updateStrategy.rollingUpdate.maxUnavailable
flag.
1.10.4
February 22, 2023
Updates
- Added a new annotation
portworx.io/is-oke=true
to the StorageCluster spec to support Portworx deployment on the Oracle Container Engine for Kubernetes (OKE) cluster.
Fixes
- Fixed a bug where the Portworx PVC controller leader election resources conflicted with the resources used by the Kubernetes controller manager.
- Fixed the Anthos Telemetry installation failure. Operator now allows two sidecar containers to run on the same node.
1.10.3
January 27, 2023
Fixes
- An issue with a missing node name in the Portworx pod template in Operator version 1.10.2 sometimes scheduled the Portworx pod on a random node. This node name is no longer missing, and Portworx is now scheduled correctly.
1.10.2
January 24, 2023
Updates
- Stork now uses
KubeSchedulerConfiguration
for Kubernetes version 1.23 or newer, so that pods are evenly distributed across all nodes in your cluster.
1.10.1
Dec 5, 2022
Updates
- Added support for Kubernetes version 1.25, which includes:
- Removed
PodSecurityPolicy
when deploying Portworx with Operator. - Upgraded the API version of
PodDisruptionBudget
from policy/v1beta1 to policy/v1
- Removed
- Added a UI option in the spec generator to configure Kubernetes version when you choose to deploy Portworx version 2.12.
- The Portworx Operator is now deployed without verbose log by default. To enable it, add the
--verbose
argument to the operator deployment. - For CSI deployment, the px-csi-ext pods now set Stork as a scheduler in the px-csi-ext deployment spec.
- The operator now chooses
maxStorageNodesPerZone
’s default value to efficiently manage the number of storage nodes in a cluster. For more details, see Manage the number of storage nodes.
1.10.0
Oct 24, 2022
Notes
To enable telemetry for DaemonSet-based Portworx installations, you must migrate to an Operator-based installation, then upgrade to Portworx version 2.12 before enabling Pure1 integration. For more details, see this document.
Updates
- Pure1 integration has been re-architected to be more robust and use less memory. It is supported on Portworx version 2.12 clusters deployed with Operator version 1.10.
- To reduce memory usage, added a new argument
disable-cache-for
to disable Kubernetes objects from controller runtime cache. For example,--disable-cache-for="Event,ConfigMap,Pod,PersistentVolume,PersistentVolumeClaim"
. - Operator now blocks Portworx installation if Portworx is uninstalled without a wipe and then reinstalled with a different name.
- For a new installation, Operator now sets the max number of storage nodes per zone, so that the 3 storage nodes in the entire cluster are uniformly spread across zones.
Fixes
- Fixed a bug where DaemonSet migration was failing if the Portworx cluster ID was too long.
1.9.1
Sep 8, 2022
Updates
- Added support for Kubernetes version 1.24:
- Added
docker.io
prefix for component images deployed by Operator. - To determine Kubernetes master nodes, Operator now uses the
control-plane
node role instead ofmaster
.
- Added
Fixes
- In Operator 1.9.0, when you enabled the CSI snapshot controller explicitly in the StorageCluster, the
csi-snapshot-controller
sidecar containers might have been removed during an upgrade or restart operation. This issue is fixed in Operator 1.9.1.
1.9.0
Aug 1, 2022
Updates
- Daemonset to Operator migration is now Generally Available. This includes the following features:
- The ability to perform a dry run of the migration
- Migration for generic helm chart from Daemonset to the Portworx Operator
- Support for the
OnDelete
migration strategy - Support for various configurations such as external KVDB, custom volumes, environment variables, service type, and annotations
- You can now use the
generic helm chart
to install Portworx with the Portworx Operator. Note: Only AWS EKS has been validated for cloud deployments. - Support for enabling
pprof
in order to get Portworx Operator container profiles for memory, CPU, and so on. - The operator now creates example CSI storage classes.
- The operator now enables the CSI snapshot controller by default on Kubernetes 1.17 and newer.
Fixes
- Fixed an issue where KVDB pods were repeatedly created when a pod was in the
evicted
oroutOfPods
status.
Known issues (Errata)
- When you upgrade Operator to version 1.9.0, the snapshot controller containers are removed from
px-csi-ext
deployment when theinstallSnapshotController
flag is set to true explicitly in the StorageCluster spec.
Workaround: To fix this issue, either restart Operator or upgrade to a newer version.
1.8.1
June 22, 2022
Updates
- Added support for Operator to run on IPv6 environment.
- You can now enable CSI topology feature by setting the
.Spec.CSI.Topology.Enabled
flag totrue
in the StorageCluster CRD, the default value isfalse
. The feature is only supported on FlashArray direct access volumes. - Operator now uses custom SecurityContextConstraints
portworx
instead ofprivileged
on OpenShift. - You can now add custom annotations to any service created by Operator.
- You can now configure
ServiceType
on any service created by Operator.
Fixes
- Fixed pod recreation race condition during OCP upgrade by introducing exponential back-off to pod recreation when the
operator.libopenstorage.org/cordoned-restart-delay-secs
annotation is not set. - Fixed the incorrect CSI provisioner arguments when custom image registry path contains ":".
1.8.0
Apr 14, 2022
Updates
- Daemonset to operator migration is in Beta release.
- Added support for passing custom labels to Portworx API service from StorageCluster.
- Operator now enables the Autopilot component to communicate securely using tokens when PX-Security is enabled in the Portworx cluster.
- Added field
preserveFullCustomImageRegistry
in StorageCluster spec to preserve full image path when using custom image registry. - Operator now retrieves the version manifest through proxy if
PX_HTTP_PROXY
is configured. - Stork, Stork scheduler, CSI, and PVC controller pods are now deployed with
topologySpreadConstraints
to distribute pod replicas across Kubernetes failure domains. - Added support for installing health monitoring sidecars from StorageCluster.
- Added support for installing snapshot controller and CRD from StorageCluster.
- The feature gate for CSI is now deprecated and replaced by setting
spec.csi.enabled
in StorageCluster. - Added support to enable hostPID to Portworx pods using the annotation
portworx.io/host-pid="true"
in StorageCluster. - Operator now sets
fsGroupPolicy
in the CSIDriver object toFile
. Previously it was not set explicitly, and the default value wasReadWriteOnceWithFsType
. - Added
skip-resource
annotation to PX-Security Kubernetes secrets to skip backing them to the cloud. - Operator now sets the dnsPolicy of Portworx pod to
ClusterFirstWithHostNet
by default. - When using Cloud Storage, Operator validates that the node groups in StorageCluster use only one common label selector key across all node groups. It also validates that the value matches
spec.cloudStorage.nodePoolLabel
if a is present. If the value is not present, it automatically populates it with the value of the common label selector.
Fixes
- Fixed Pod Disruption Budget issue blocking Openshift upgrade on Metro DR setup.
- Fixed Stork scheduler's pod anti-affinity by adding the label
name: stork-scheduler
to Stork scheduler deployments. - When a node level spec specifies a cloud storage configuration, we no longer set the cluster level default storage configuration. Before this fix, the node level cloud storage configuration would be overwritten.