Apr

v3.3 - Preview SaaS¶

Expected Rollout to Prod Orgs: April 4, 2025

Amazon EKS¶

Bottlerocket¶

This enhancement supports updating Bottlerocket settings like data and trusted properties, as part of the Bottlerocket configuration. This enhancement allows users to update the Bottlerocket certificate bundle in the data field during Day 2 operations before it expires.

Previously, modifying Bottlerocket settings for a managed node group was not supported. Users can now update configurations such as:

bottlerocket:
  settings:
    pki:
      my-trusted-bundle:
        data: LS0tLS1CRUxxxxxxxxxxxxxxxxxxxxxBase 64 Certificate Dataxxxxxxxx
        trusted: true

Since this property change requires creating a new launch template version internally, updating Bottlerocket settings will result in a rolling replacement of EC2 instances within the same node group. This ensures that the new Bottlerocket settings are applied as part of the bootstrapping process for EC2 machines.

Note

Support for updating Bottlerocket settings is available in interfaces such as RCTL, Terraform, API, and SystemSync. UI support will be added in the next release.

Day 2 Support for Updating Tags in Managed Node Groups¶

Previously, tag updates made during Day 2 operations were not reflected in the launch template of the managed node group. This is now being addressed.

With this enhancement, users can add new tags, and these updates will be correctly applied to the launch template as part of the managed node group configuration.

To apply Day 2 tag changes, a new launch template version will be created incorporating the updated tags. As a result, the nodes in the managed node group will be recycled, ensuring the new tags are effectively applied.

Blueprints¶

Support for Draft Versions¶

Support has been added to mark versions as 'Draft' for Add-ons and Blueprints, providing the following benefits:

The platform team can modify Add-ons and Blueprints multiple times during the testing and validation phase without creating a new version each time. Once all necessary changes are complete, the version can be marked as 'Active'
Draft versions are project-scoped, meaning they are not shared with downstream projects. This ensures that only fully vetted Blueprints, explicitly marked as 'Active', are accessible to downstream projects and users.

Note

This feature will initially be supported with non-UI interfaces. Support with UI interface will be added in a subsequent release.

Configurable Add-on/Workload Retries¶

Blueprints and Workloads incorporate health readiness checks to determine when a deployment of YAML/Helm manifest is successful.

In some cases, the failure status takes longer than expected to appear, even when an issue with the deployment is evident. This delay occurs due to multiple readiness check retries.

With this enhancement, users can now configure the number of readiness check retries, offering greater flexibility to fine-tune the process based on the type of manifest being deployed. This setting can be adjusted through Add-on/Workload overrides.

By default, the number of readiness retries is set to 5.

Integrations¶

OCI Helm Repository¶

Support is being added for OCI Helm repositories, enabling users to deploy Helm charts directly from OCI-compliant container registries. This enhancement allows seamless integration with OCI-based repositories.

With this capability, users can also create a custom catalog and leverage OCI-based repositories for efficient Helm chart management and distribution.

Secrets Management¶

Search by name has been added to the Secrets Provider Classes page to make it easier to find specific entries.

Workloads & GitOps Pipelines¶

UI improvements¶

Several backend enhancements have been implemented to improve the loading speed of the workload listing page, including faster retrieval of deployment status.

Error Handling and Reporting¶

Several improvements are being implemented to simplify troubleshooting for Workload failures. These enhancements include co-relating Kubernetes events to surface more meaningful error messages from the cluster, making it easier to identify the root cause of deployment failures.

Workload Debug

Deploy Workload Stage¶

When creating a Deploy Workload stage within a GitOps pipeline, workloads are now listed in alphabetical order in the dropdown. Additionally, type-ahead search with auto-suggestions is supported as characters are entered.

Filtering¶

Now, when navigating into a workload or pipeline, making changes, and returning, your previously applied filters are retained—eliminating the need to reapply them.

Env Manager¶

Skip Condition for hooks¶

A previous release introduced the "Skip Condition" feature for tasks and hooks. This functionality is now also supported in the UI interface

Environment Templates¶

A search box has been added to the resource template selection step, making it easier to find the desired template when creating an environment—especially when many resource templates are available.

Projects¶

Delete Project API in v3¶

Support is being added for project deletion using the v3 API.

Helm App Catalog¶

The Helm App Catalog has been updated to add support for the following repositories.

Category	Description
AI/ML	Apache Yunikorn
AI/ML	Kueue
Kubernetes Lifecycle Management	Karpenter
AI/ML	JobSet

System Templates¶

The following system templates are being introduced or enhanced and will be available in the System Template Catalog.

Cluster Lifecycle Templates¶

#	Template Name	Description
1	system-eks	Standardizes cluster provisioning and management with Amazon Elastic Kubernetes Service (EKS).

Bug Fixes¶

Bug ID	Description
RC-40716	Resolved an issue where clusters created prior to the 3.2 release without the create_account field under workload-identities would fail validation during blueprint updates via Terraform
RC-40503	Fixed an issue where EKS add-on configuration values were unintentionally overwritten during cluster upgrades
RC-39697	Fixed an issue where opting out of schedules in an environment would reset parameters to their default values
RC-39669	Resolved an issue where users with both "Infrastructure Read-Only" and "Namespace Admin" roles were granted unintended access to view registries