Skip to main content
Version: Next

Release Notes

6.12.0 (2025-04-02)​

🚨 Upgrade Notices​

  • Kyverno
    • A new Kyverno Policy has been added which mutates pod specs to drop ALL capabilities in all containers if not already done. This policy works in tandem with the require-drop-all-capabilities policy to make it easier for SREs to securely deploy workloads to their clusters without having to explicitly modify the pod's containers' securityContexts to be compliant.
    • If Big Bang consumers are currently excluding certain workloads from the require-drop-all-capabilities policy due to incompatibilities with that policy, those exclusions should also be included for this new policy: add-default-capability-drop to avoid workload interruption.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.12.0 includes Big Bang Version 2.49.0. For more details on the features and updates included in Big Bang Version 2.49.0, please refer to the Big Bang Release Notes.
  • console updated image to 54183
  • nexus-iq chart upgraded to 188

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.9-rke2r1
    • K3s: v1.30.9+k3s1
    • EKS: v1.30.8
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.9-rke2r1-rocky-8-base-v1.1.1-stig-2025-02-17T09-24-30Z
    • EKS AMI: smoothglue-eks-1.30.8-rocky-8-base-v1.1.1-stig-2025-02-10T09-21-19Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-02-10T0802

6.11.0 (2025-03-19)​

🚨 Upgrade Notices​

  • Flux has been upgraded to 2.5.1. Platform Operators should update their local Flux binary to a compatible version.

📦 SmoothGlue Features​

  • On RKE2-based clusters, the preserve_client_ips IaC variable is now set to false by default in order to allow pods to communicate internally using external DNS names. See the known issues section for more information.
    Note: This means that the client IP in any logs will appear to be the load balancer itself. To get the true client IP, you will need to setup monitoring on the NLB
  • Added documentation for manually rotating RDS/Aurora database passwords as a good security practice.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.11.0 includes Big Bang Version 2.48.0. For more details on the features and updates included in Big Bang Version 2.48.0, please refer to the Big Bang Release Notes.
  • Update Gitlab to 17.9.2 (applied Critical Patch)
  • Update Jira to LTS 10.3.4 (addresses CVE-2024-38819)
  • Update JSM to 10.3.4 (addresses CVE-2024-38819)

🐞 Bug Fixes​

  • Fixed an issue with the SmoothGlue automated SSO feature for ArgoCD. SmoothGlue Admins should now be correctly given admin privileges in ArgoCD.

❗ Known Issues​

  • When using a network load balancer (NLB) with the preserve_client_ip option enabled, the default routing rules for EKS nodes prevent nodes from accessing platform services hosted on the same node, which can cause failures when logging into Keycloak, particularly on clusters with fewer nodes.
    • More specifically, the default routing rules for nodes do not route traffic to the VPC router for traffic within the node’s local subnet, since these addresses should theoretically be reachable directly by the node. However, when using the preserve_client_ip option, the VPC router rewrites the source IP for traffic; when the node attempts to talk to the NLB, the traffic is rewritten so that it appears to come from the node itself, and the return traffic is not able to be routed correctly back to the NLB.
    • The following options are potential workarounds:
      • Disabling the preserve_client_ip option on the NLB will resolve the issue at the cost of losing source attribution for incoming traffic.
      • Removing the local subnet route on nodes will resolve the issue at the cost of increasing the amount and cost of traffic being routed through the VPC router.
      • Increasing the node count for the cluster will reduce the likelihood of the issue because it will become less likely for any given traffic to be routed back to the original node.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.9-rke2r1
    • K3s: v1.30.9+k3s1
    • EKS: v1.30.8
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.9-rke2r1-rocky-8-base-v1.1.1-stig-2025-02-17T09-24-30Z
    • EKS AMI: smoothglue-eks-1.30.8-rocky-8-base-v1.1.1-stig-2025-02-10T09-21-19Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-02-10T0802

6.10.0 (2025-03-04)​

SmoothGlue Features​

  • This release adds optional basic support for Amazon Linux 2023 (AL2023) AMIs in EKS cluster IaC. To use AL2023, add the following to the cluster_inputs section of your env.hcl file: 
    locals {
      cluster_inputs = {
        ami_id           = "ami-0123456789abcdef0"  # replace with actual AMI ID
        default_ami_type = "AL2023_x86_64_STANDARD"
      }
    }
  • This release adds optional support in IaC for provisioning GitLab's database using an RDS Multi-AZ cluster rather than a single database instance. As a single instance, RDS offers support for a single warm standby instance; however, provisioning the database using an RDS Multi-AZ cluster allows for a cluster of three instances. There is no automatic migration path from a single RDS instance to a Multi-AZ cluster, so we recommend enabling the Multi-AZ cluster during the initial cluster provision if possible. If migrating an existing cluster, you will need to perform a database import/export manually.
    • Note that there are instance class limitations when using a Multi-AZ RDS cluster; see the AWS documentation for more information.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.10.0 includes Big Bang Version 2.47.0. For more details on the features and updates included in Big Bang Version 2.47.0, please refer to the Big Bang Release Notes.
  • Update Confluence to LTS 9.2.1 (Helm chart version 1.22.5-bb.0).
  • Update Jira to LTS 10.3.3 (Helm chart version 1.22.5-bb.1).

🪲 Bug Fixes​

  • Refactor IaC compatibility mode toggle to correctly disable NLB stickiness in ISO regions.
  • Exclude aws-ebs-csi-driver namespace from generate-networkpolicy-imds Kyverno ClusterPolicy so that RKE2 clusters can provision EBS PVCs correctly.
  • Exclude the following namespaces from the require-istio-on-namespaces Kyverno ClusterPolicy so that users may enforce the policy:
    • cluster-autoscaler
    • crossplane-system
    • kyverno
    • structsure-system
  • Extend HelmRelease install timeout for GitLab to 15 minutes.

❗️ Known Issues​

  • When using a network load balancer (NLB) with the preserve_client_ip option enabled, the default routing rules for EKS and RKE2 nodes prevent nodes from accessing platform services hosted on the same node, which can cause failures when logging into Keycloak, particularly on clusters with fewer nodes.
    • More specifically, the default routing rules for nodes do not route traffic to the VPC router for traffic within the node's local subnet, since these addresses should theoretically be reachable directly by the node. However, when using the preserve_client_ip option, the VPC router rewrites the source IP for traffic; when the node attempts to talk to the NLB, the traffic is rewritten so that it appears to come from the node itself, and the return traffic is not able to be routed correctly back to the NLB.
    • We are currently working on an Istio-level fix which should prevent VirtualService traffic within the cluster from ever leaving the cluster. Until that fix is available, the following options are potential workarounds:
      • Disabling the preserve_client_ip option on the NLB will resolve the issue at the cost of losing source attribution for incoming traffic.
      • Removing the local subnet route on nodes will resolve the issue at the cost of increasing the amount and cost of traffic being routed through the VPC router.
      • Increasing the node count for the cluster will reduce the likelihood of the issue because it will become less likely for any given traffic to be routed back to the original node.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.9-rke2r1
    • K3s: v1.30.9+k3s1
    • EKS: v1.30.8
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.9-rke2r1-rocky-8-base-v1.1.1-stig-2025-02-17T09-24-30Z
    • EKS AMI: smoothglue-eks-1.30.8-rocky-8-base-v1.1.1-stig-2025-02-10T09-21-19Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-02-10T0802

🔗 Helpful Links​

6.9.0 (2025-02-19)​

🚨 Upgrade Notices​

  • During upgrade, you may get a SonarQube is under maintenance error message on the SonarQube UI.
    • To resolve this, once the HelmRelease upgrades, you will be prompted to visit your SonarQube instance at a <sonarqube_url>/setup URL.

📦 SmoothGlue Features​

  • Crossplane Upgraded the Crossplane and provider-kubernetes Crossplane components.
  • IaC: Added HA support for RDS Aurora modules:
    • Supported Applications:
      • Jira
      • Confluence
      • Mattermost
      • SonarQube
      • Nexus
      • Console
      • Keycloak
    • For any of the above modules, you can now add more than one RDS instance into a cluster. Additional instances will be Reader instances only. If the main Writer instance goes down, Aurora will automatically promote a Reader instance to Writer.
      • For each instance created, values such as the availability zone can be manually set; however, you do not have to specify AZ for each instance; Aurora will automatically place each instance in a different AZ.
      • All RDS Aurora storage is automatically replicated across multiple AZs regardless of DB instance count.
      • Examples

        • To create a writer instance and two reader instances for keycloak in your env.hcl:

          keycloak_inputs = {
            # Allows a specific number of database instances to be defined
            rds_instances = {
              primary     = {availibility_zone = us-east-1a}
              secondary   = {}
              replica1    = {}
              # ...
            } 
          }

        • Autoscaling of instances is also optionally available. Aurora autoscaling will NOT scale any instances explicitly defined in rds_instances; it will only add or remove reader instances up to the defined min and max limits. Autoscaling will use the target_metric scaling policy by default with a target CPU utilization of 70%. The following env.hcl provisions Keycloak RDS Aurora autoscaling with between 0 and 5 reader instances:

          keycloak_inputs = {
            rds_auto_scale = {
              enabled = true
              min = 0 # default is 0
              max = 5 # default is 5
            }
          }

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.9.0 includes Big Bang Version 2.46.0. For more details on the features and updates included in Big Bang Version 2.46.0, please refer to the Big Bang release notes.
  • Confluence: confluence-node:9.2.0 version: 1.22.3-bb.4
    • Removed duplicate jmx-initContainer
    • Updated cypress (source) 14.0.0 -> 14.0.1
  • Jira: jira-node-lts:10.3.2. version: 1.22.3-bb.0
    • Updated chart to 1.22.3
    • Updated cypress (source) 14.0.0 -> 14.0.1
  • Nexus IQ: Upgraded from 1.186.0-01 to 1.187.0-01
  • Crossplane Components:
    • crossplane - v1.16.0 to v1.19.0
    • provider-kubernetes - v0.12.1 to 0.16.2

❗ Known Issues​

  • If turning on new components, Zarf health checks are performed before unsuspending Big Bang. Manually resume the Big Bang HelmRelease, as required.
  • Big Bang 2.46.0 comes with a known issue relating to the gitlab-gitlab-exporter ServiceMonitor object. We are handling this issue as part of our upgrade process; no user action should be required. More information may be found here.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.9+rke2r1
    • K3s: v1.31.5+k3s1
    • EKS: v1.30.8-eks-2d5f260
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.9-rke2r1-rocky-8-base-v1.1.1-stig-2025-02-17T09-24-30Z
    • EKS AMI: smoothglue-eks-1.30.6-rocky-8-base-v1.1.1-stig-2025-01-04T03-12-26Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

6.8.0 (2025-02-06)​

🚨 Upgrade Notices​

  • SmoothGlue packages are now built with Zarf v0.46.0, which is the minimum version supported. Please zarf init pre-existing clusters with the v0.46.0 init package before upgrading SmoothGlue.

  • The new Zarf version provides better package readiness checking. As a byproduct, the logic in the package has less control over when and what is evaluated. The default readiness timeout set by Zarf is too low for deploying a fresh cluster. It is recommended to add the following to the ZARF_CONFIG file:

    package:
      deploy:
        timeout: 30m0s

  • Due to the better readiness checks from Zarf, clusters that do not wish to use the automated SSO feature need to disable it from the config. Run clusters have it disabled by default, but for build clusters it is recommended to include the following to the ZARF_CONFIG file to opt out of the automated SSO feature:

    package:
      deploy:
        set:
          KEYCLOAK_CONFIG_ENABLED: false

  • This release will cause a node refresh to occur.

📦 SmoothGlue Features​

  • IaC Allow overriding EKS-calculated max-pods per node.

⏩ Upgraded Packages​

  • Upgraded Zarf to v0.46.0
  • Upgraded Confluence to confluence-node:9.2.0 version: 1.22.3-bb.2
    • Updated gluon from 0.5.12 to 0.5.14
    • Updated cypress dependencies 13.12.0 -> ^14.0.0
    • Updated registry1.dso.mil/ironbank/opensource/postgres/postgresql from 16.6 to 17.2
  • Upgraded Jira to jira-node-lts:10.3.2 version: 1.22.2-bb.4
    • Added gluon 0.5.12 -> 0.5.14
    • Updated cypress ^13.15.0 -> ^14.0.0
    • Updated registry1.dso.mil/ironbank/atlassian/jira-data-center/jira-node-lts 10.3.1 -> 10.3.2
  • This release of SmoothGlue Enterprise v6.8.x includes Big Bang Version 2.45.1. For more details on the features and updates included in Big Bang Version 2.45.1, please refer to the Big Bang Release Notes.
    • Promtail: Note: bumping promtail image/appVersion beyond the version used in upstream chart (v3.0.0 vs v3.3.2)
    • Mattermost upgrade from 10.4.1 to 10.4.2
    • GitLab upgrade from 17.6.2 to 17.8.1

🪲 Bug Fixes​

  • Standardize Terraform provider versions to resolve lookup inconsistencies.
  • Nexus can be enabled with nexus = true or nexusRepositoryManager = true, allowing for conditional enablement of Nexus Repository Manager.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.8-rke2r1
    • K3s: v1.30.5+k3s1
    • EKS: v1.30.8-eks-2d5f260
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.8-rke2r1-rocky-8-base-v1.1.1-stig-2025-01-13T09-22-54Z
    • EKS AMI: smoothglue-eks-1.30.6-rocky-8-base-v1.1.1-stig-2025-01-04T03-12-26Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

🔗 Helpful Links​

6.7.0 (2025-01-22)​

📦 SmoothGlue Features

  • Kubernetes v1.30.x is officially supported and is the default version used to test SmoothGlue on EKS/RKE2. Additional testing is performed for Kubernetes v1.31.x using K3s.
  • IaC: allow autoscaling on a per-nodegroup basis with supporting documentation. Cluster autoscaler will be enabled by default on the main nodegroup. Additional nodegroups can be explicitly defined via tags.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.7.0 includes Big Bang Version 2.44.0. For more details on the features and updates included in Big Bang Version 2.44.0, please refer to the Big Bang release notes.
  • console updated image to 39560
  • nexus-iq chart upgraded to 186
  • cluster-autoscaler upgrade to support Kubernetes v1.30.x

❗ Known Issues​

  • Kiali - ISSUE

    • On Kubernetes 1.29+, the Kiali Operator may fail with a 404 while running the kiali-deploy playbook if the cluster returns the flowcontrol.apiserver.k8s.io/v1beta2 API version (no longer served as of v1.29).

      In this case, removing the invalid API version should resolve the issue and allow the Kiali Operator to run successfully.

 $ kubectl delete apiservices.apiregistration.k8s.io v1beta2.flowcontrol.apiserver.k8s.io

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.36.1.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.8-rke2r1
    • K3s: v1.30.5+k3s1
    • EKS: v1.30.8-eks-2d5f260
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.30.8-rke2r1-rocky-8-base-v1.1.1-stig-2025-01-13T09-22-54Z
    • EKS AMI: smoothglue-eks-1.30.6-rocky-8-base-v1.1.1-stig-2025-01-04T03-12-26Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

6.6.0 (2025-01-07)​

🚨 Upgrade Notices​

  • :octagonal_sign: With a Major version update to Jira 10.3 you must also update the SSO addon, this is not provided for you if you are running Jira in a disconnected environment.

📦 SmoothGlue Features​

  • Adds Grafana Dashboard / Alerts for monitoring failed Keycloak login attempts by Username and IP
  • Jira has a major version update that changes how users SSO login, To force users to have to login again see this guide

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.6.0 includes Big Bang Version 2.43.0. For more details on the features and updates included in Big Bang Version 2.43.0, please refer to the Big Bang release notes.
    • Jira has received a major version to 10

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.36.1.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.29.8+rke2r1
    • K3s: v1.30.5+k3s1
    • EKS: v1.29.6
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.29.8-rke2r1-rocky-8-base-v1.1.1-stig-2024-09-23T08-14-20Z
    • EKS AMI: smoothglue-eks-1.29.6-rocky-8-base-v1.1.1-stig-2024-09-09T08-14-46Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

6.5.0 (2024-12-30)​

🚨 Upgrade Notices​

If you see a :octagonal_sign: it means that some form of manual step is required to proceed, please heed these warnings.

  • :octagonal_sign: Zarf version required is now v0.36.1 to support new functionality around deploying OCI artifacts. Upgrading existing clusters requires using the new version to zarf init the cluster to upgrade onto the new version
  • :octagonal_sign: Due to a FIPs compliance issue in the Big Bang's version of Gitlab you MUST upgrade the RDS for GitLab from Postgres version 14 to version 16 while staying on the same version of GitLab. It is recommended to upgrade to Postgres 16 before attempting to upgrade via the IaC. Steps to manually upgrade GitLab RDS:
    • Fully backup GitLab and store backup in secure location
    • Scale down GitLab deployments and statefulsets
    • Go to AWS console and find your GitLab instance (ity won't be in a cluster)
    • Click Modify in the top right
    • Change DB engine version to 16.X
    • Scroll to "additional configurations" --> "Database options"
    • Change DB parameter group to default.postgres16
    • Click continue and BE SURE TO SELECT Apply Immediately
      • AWS will take ~10 minutes to upgrade. Please make sure the RDS is done upgrading before proceeding.
    • Now run the IaC for 6.5. The IaC should accept the database engine version 16 and create a new aws_db_parameters with the 16 family
  • :octagonal_sign: The Terraform EKS module and a major change to how roles attach to the Cluster has been implemented.
    • If you encounter an error in the Terragunt/Terraform with the object called aws_eks_access_entry due to the object already existing, you must:
    • terragrunt import 'module.eks.aws_eks_access_entry.this["<Your access entry name In the HCL>"]' <cluster name>:arn:aws:iam::<aws account>:role/ec2/<Role id>
  • :octagonal_sign: This release updates the Terraform module for AWS EKS from major version 19 to 20, which enables support for EKS cluster access entries. We recommend migrating from the aws-auth ConfigMap to cluster access entries, as this will become the preferred authentication mode for EKS clusters moving forward.

    • For a role which was previously defined using the following parameter in the env.hcl:

      aws_auth_roles = [
        {
          rolearn  = "arn:aws:iam::012345678901:role/AWSReservedSSO_AdministratorAccess_0123456789abcdef",
          username = "AWSReservedSSO_AdministratorAccess_0123456789abcdef",
          groups = [
            "system:masters",
          ]
        },
      ]

      The following access entry is equivalent:

      access_entries = {
        admin = {
          principal_arn = "arn:aws:iam::012345678901:role/aws-reserved/sso.amazonaws.com/us-east-2/AWSReservedSSO_AdministratorAccess_0123456789abcdef"
          policy_associations = {
            cluster_admin = {
              policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
              access_scope = {
                type = "cluster"
              }
            }
          }
        }
      }

    • For existing clusters which are migrating to the API_AND_CONFIG_MAP authentication method, an existing access entry for the cluster creator will be exposed during the migration. was previously not visible when using aws-auth ConfigMap, but will become visible when access entry is enabled. If you are defining a cluster access entry for this IAM entity, it must be imported into Terraform using the following command:

      terragrunt import 'module.eks.aws_eks_access_entry.this["<access_entry_key"]' <eks_cluster_name>:<arn_of_iam_entity>

    • By default, the created EKS clusters will enable authentication via both the newly-enabled cluster access entries, as well as the legacy aws-auth ConfigMap.

      • If you are relying upon the aws-auth ConfigMap in an existing cluster, note that due to major version 20 of the EKS module removing the aws-auth functionality from the core of the module, the aws-auth ConfigMap is created using a separate submodule. This means the existing ConfigMap will be re-created during the Terraform apply process, and any users whose permissions are defined only in the aws-auth ConfigMap may temporarily lose access to the cluster until the ConfigMap is re-created. This should be a one-time process.

    • This version adds the following new variables to the eks-cluster Terraform module:

      • authentication_mode: Determines the enabled EKS authentication modes, defaults to (API_AND_CONFIG_MAP).
      • access_entries: A map of the cluster access entries for the cluster, see the example env.hcl for more information.
      • enable_cluster_creator_admin_permissions: Automatically creates a cluster access entry for the identity running the Terraform module. (This should not be set to true if an explicit access entry is being created for this identity).
  • :octagonal_sign: Due to a Big Bang update for Kyverno 1.13.0 that deprecated how cluster policies are generated and the fact that cluster policies are immutable; the old cluster policies must be manually deleted to allow for the same policies to be recreated. If you have your own custom cluster policies that used generate-XYZ please see Upstream Kyverno release notes to ensure that they follow the new standards. https://kyverno.io/blog/2024/10/30/announcing-kyverno-release-1.13/
    • kubectl delete clusterpolicy generate-networkpolicy-imds
    • kubectl delete clusterpolicy generate-private-git-server-secret
  • ❗ In kyverno update to v1.13 they have remove wildcard permissions which allowed Kyverno controllers to view all resources. We have added back in the wildcard permissions for the time being but all users should follow best practices and remove them
  • ❗ The EKS terraform module update will cause a node rotation, this can take a long time depending on your availability settings and terraform might time out until the EKS node group is back into an active state
  • ❗ GitLab HR will succeed but there will be a job that fails called gitlab-gitlab-upgrade-check, you can delete the job as it is just a warning

📦 SmoothGlue Features​

  • iac: enable specifying EKS cluster log types to save to cloudwatch
  • iac: update eks tf module, support eks cluster access entries

⏩ Upgraded Packages​

🐞 Bug Fixes​

  • This fix restores RKE2 functionality (NeuVector is not working), which has been broken since SmoothGlue release 6.2.0.
  • The AWS EFS CSI driver add-on has been locked down to version v2.1.0 for EKS. The latest version v2.1.1 gives EFS mount failure issues with NeuVector, Jira and Confluence.
  • zarf: add deny imds exclusion for aws-efs-csi-driver

❗ Known Issues​

  • There is a chance that the Kiali pod will be stuck in a non functional state, rotate the pod and it should fix itself
  • crossplane-provider-keycloak might be stuck in an unhealthy state, to remedy find the providerrevision.pkg.crossplane.io for the crossplane-provider-keycloak and force delete it so it can be recreated. This is will be for both run and build.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.36.1.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.29.8+rke2r1
    • K3s: v1.30.5+k3s1
    • EKS: v1.29.6
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.29.8-rke2r1-rocky-8-base-v1.1.1-stig-2024-09-23T08-14-20Z
    • EKS AMI: smoothglue-eks-1.29.6-rocky-8-base-v1.1.1-stig-2024-09-09T08-14-46Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

Other Changes​

  • console: deploy chart from OCI artifact (d3f1c74)**