Skip to content

23.2.0
Compare
Choose a tag to compare
@puresandra puresandra released this 10 Mar 01:02
· 478 commits to master since this release
v23.2.0
1f0d653
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Notes:

  • Starting with 23.2.0, the naming scheme for Stork releases has changed. Release numbers are now based on the year and month of the release.
  • Customers upgrading to stork 23.2.0 will need to update storkctl on their cluster. This is required to correctly set up migration with Auto Suspend.

Improvements

  • Stork will migrate all the CRDs under the same group for which CR exists if it is for a different kind. #1269
  • Stork will update the owner reference for PVC objects on the destination cluster. #1269
  • Added support for gke-gcloud-auth-plugin required for authenticating with GKE. #1312

Bug Fixes

  • Issue: Users were unable to migrate Confluent Kafka resources during failback.
    User Impact: Confluent Kafka application failback was unable to bring up the application.
    Resolution: Stork will now remove any finalizers on the CRs when deleting the resource during migration so that a new version of the resource can be recreated. #1295

  • Issue: Migration was suspended after failback if autosuspend was enabled.
    User Impact: After failback, the existing migration schedule was not being resumed, which caused the secondary cluster not to sync.
    Resolution: With the fix, the primary cluster's migration schedule will correctly detect if migration can be resumed to secondary. #1282

  • Issue: The Confluent Kafka operator was not able to recognize service sub resources during Async-DR migration.
    User Impact: Application pods for Confluent Kafka were not able to start.
    Resolution: Stork will not migrate Service resources if the owner reference field is set. #1269

  • Issue: Stork was throwing the error Error migrating volumes: Operation cannot be fulfilled on migrations.stork.libopenstorage.org: the object has been modified; please apply your changes to the latest version and try again.
    User Impact: This error caused unnecessary confusion during migration.
    Resolution: Stork no longer raises this event as it retries the failed operation. #1272, #1293

  • Issue: Users were not allowed to take backups based on namespace labels.
    User Impact: Users had to manually select the static namespaces list for backup schedules. Dynamic selection of the namespace list based on the namespace label was not possible.
    Resolution: With namespace label support, users can specify the namespace label such that the list of namespaces with those label will be selected dynamically for backups. #1258, #1315

  • Issue: The Rancher project association for the Kubernetes resources in the Rancher environment was not backed up and restored.
    User Impact: Since the project configurations are not restored, some applications failed to come up.
    Resolution: Project settings are now backed up and applied during the restore. Users can also change to a different project with project mapping during restore. #1294, #1318

  • Issue: Users were not able to specify the option to use the default storage class configured on the restore cluster in storage class mapping.
    User Impact: Users were not able to use the default storage class for restore.
    Resolution: Now users can mention use-default-storage-class as the destination storage class in the storage class mapping if they want to use the default configure storage class from the restore cluster. #1288

Assets 2
Loading