Skip to content

23.11.0

Latest
Latest
Compare
Choose a tag to compare
@hemadrid hemadrid released this 22 Jan 04:23
v23.11.0
03377da

New Features

  • You can now create and delete schedule policies and migration schedules using the new storkctl CLI feature. This enables you to seamlessly create and delete SchedulePolicy and MigrationSchedule resources, enhancing the DR setup process.
    In addition to the existing support for clusterPairs, you can now efficiently manage all necessary resources through storkctl. This update ensures a faster and simpler setup process, with built-in validations. By eliminating the need for manual YAML file edits, the feature significantly reduces the likelihood of errors, providing a more robust and user-friendly experience for DR resource management in Kubernetes clusters.

  • The new Storage Class parameter preferRemoteNode enhances scheduling flexibility for SharedV4 Service Volumes. By setting this parameter to false, you can now disable anti-hyperconvergence during scheduling. This provides an increased flexibility to tailor Stork's scheduling behavior according to your specific application needs.

Enhancement

  • Updated golang and google-cloud-sdk versions to resolve security vulnerabilities. #1587, #1588

Bug Fixes

  • Issue: Exclusion of Kubernetes resources such as deployments, statefulsets, and so on was not successful during migration.
    User Impact: The use of labels to exclude selectors proved ineffective in scenarios where the resource was managed by an operator that reset user-defined labels.
    Resolution: The introduction of the excludeResourceTypes feature now allows users to exclude certain types of resources from migration, providing a more effective solution compared to using labels. #1554

  • Issue: The applicationrestore function created using storkctl consistently restored to a namespace with the identical name as the source, causing users to be unable to restore to a different namespace.
    User Impact: Users faced limitations as they were unable to restore applications to a namespace other than the one with the same name as the source.
    Resolution: storkctl has been updated to address this issue by introducing support for accepting namespace mapping as a parameter, allowing users to restore to a different namespace as needed. #1545

  • Issue: The storkctl create clusterpair command was not functioning properly with HTTPS PX endpoints.
    User Impact: Migrations between clusters with SSL-enabled PX endpoints were not successful.
    Resolution: The issue has been addressed, and now both HTTPS and HTTP endpoints are accepted as source (src-ep) and destination (dest-ep) when using storkctl create clusterpair. #1537

  • Issue: The PostgreSQL operator generates an error related to the pre-existence of service account, role, and role bindings following a migration.
    User Impact: Users are unable to scale up a PostgreSQL application installed via OpenShift Operator Hub after completing the migration.
    Resolution: Excluded migration of service account, role, and role bindings if they have owner reference set to allow PostgreSQL pods to come up successfully. #1560

  • Issue: Real-Time Custom Resource (RT CR) enters a failed state when a transform rule includes either int or bool as a data type.
    User Impact: Migration involving resource transformation will not succeed.
    Resolution: Resolved the issue by addressing the parsing problem associated with int and bool types. #1532

  • Issue: Continuous crashes occur in Stork pods when the cluster contains a RT CR with a rule type set as slice and the operation is add.
    User Impact: Stork service experiences ongoing disruptions.
    Resolution: Implemented a solution by using type assertion to prevent the panic. Additionally, the problematic SetNestedField method is replaced with SetNestedStringSlice to avoid panics in such scenarios. You can also temporarily resolve the problem by removing the RT CR from the application cluster. #1530

  • Issue: Stork crashes when attempting to clone an application with CSI volumes using Portworx.
    User Impact: Users are unable to clone applications if PVCs in the namespaces utilize Portworx CSI volumes.
    Resolution: Now, a patch is included to manage CSI volumes with Portworx, which ensures the stability of application cloning functionality. #1591

  • Issue: When setting up a migration schedule in the admin namespace with pre/post-execution rules, these rules must be established in both the admin namespace and every namespace undergoing migration.
    User Impact: The user experience is less intuitive as it requires creating identical rules across multiple namespaces.
    Resolution: The process is now simplified as rules only require addition within the migration schedule's namespace. #1569

  • Issue: Stork was not honoring locator volume labels correctly when scheduling pods.
    User Impact: In cases where preferRemoteNodeOnly was initially set to true, pods sometimes failed to schedule. This issue was particularly noticeable when the Portworx volume setting preferRemoteNodeOnly was later changed to false, and there were no remote nodes available for scheduling.
    Resolution: Now, even in scenarios where remote nodes are not available for scheduling, pods can be successfully scheduled on a node that holds a replica of the volume. #1606

Known Issues

  • Issue: In Portworx version 3.0.4, several migration tests fail in an auth-enabled environment. This issue occurs specifically when running these tests in environments where authentication is enabled.
    User Impact: You may experience failed migrations, which will impact data transfer and management processes.
    Resolution: The issue has been resolved in Portworx version 3.1.0. Users experiencing this problem are advised to upgrade to version 3.1.0 to ensure smooth migration operations and avoid permission-related errors during data migration processes.

  • Issue: When using the storkctl create clusterpair command, the HTTPS endpoints for Portworx were not functioning properly.
    User Impact: This issue affects when you attempt migrations between clusters where px endpoints were secured with SSL. As a result, migrations could not be carried out successfully in environments using secure HTTPS connections.
    Resolution: In the upcoming Portworx 3.1.0 release, the storkctl create clusterpair command will be updated to accept both HTTP and HTTPS endpoints, allowing the specification of either src-ep or dest-ep with the appropriate scheme. This update ensures successful cluster pairing and migration in environments with SSL-secured px endpoints.

Assets 2