🛜 RSS feed

Changelog entry types

Changelog entries are categorized into the following types:

  • Dependency Bumps: The version for a dependency in Gloo is bumped in this release. Be sure to check for any Breaking Change entries that accompany a dependency bump.
  • Breaking Changes: An API is changed in a way that is not backwards compatible, such as a changed format for an API field. Occasionally, a breaking change occurs for the process to upgrade Gloo, in which the changelog entry indicates how to use the new upgrade process.
  • Helm Changes: The installation Helm chart is changed. If this change is not backwards compatible, an accompanying Breaking Change entry is indicated for the release.
  • New Features: A new feature is implemented in the release.
  • Fixes: A bug is resolved in this release.

Known issues

The Solo team fixes bugs, delivers new features, and makes changes on a regular basis as described in the changelog. Some issues, however, might impact many users for common use cases. These known issues are as follows:

  • Gloo version 2.3.14: Do not install or upgrade Gloo Mesh to version 2.3.14, which contains a bug that causes the Gloo agent to have stale service discovery data. This bug is fixed in the 2.3.15 release.
  • Cluster names: Do not use underscores (_) in the names of your clusters or in the kubeconfig context for your clusters.
  • OTel pipeline:
    • If you set up the Gloo OpenTelemetry (OTel) pipeline prior to Gloo Mesh version 2.3, your installation continues to use the OTel pipeline after you upgrade to 2.3. However, due to a service name change for telemetry components, you must update the telemetry gateway IP address that the collector agents send metrics to. For more information, see the OTel pipeline notes in the version 2.3 migration guide.
    • FIPS-compliant builds are not currently supported for the OTel collector agent image.
  • Bring your own Prometheus: If you used your own Prometheus instance to scrape metrics in your cluster instead of using the built-in Prometheus, enter the Prometheus URL that your instance is exposed on, such as http://kube-prometheus-stack-prometheus.monitoring:9090, in the common.prometheusUrl field. You can get this value from the --web.external-url field in your Prometheus Helm values file or by selecting Status > Command-Line-Flags from the Prometheus UI. Do not use the FQDN for the Prometheus URL.
  • Istio:
    • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Gloo Mesh Gateway) on AWS Fargate. For more information, see the Amazon EKS issue.
    • The WasmDeploymentPolicy Gloo CR is currently unsupported in Istio versions 1.18 and later.
    • For FIPS-compliant Solo distributions of Istio 1.17.2 and 1.16.4, you must use the -patch1 versions of the latest Istio builds published by Solo, such as 1.17.2-patch1-solo-fips for Solo distribution of Istio 1.17. These patch versions fix a FIPS-related issue introduced in the upstream Envoy code. In 1.17.3 and later, FIPS compliance is available in the -fips tags of regular Solo distributions of Istio, such as 1.17.3-solo-fips.
    • Istio versions 1.14.0 - 1.14.3 have a known issue about unused endpoints failing to be deleted. Additionally, version 1.14.4 has a known issue about short hostnames causing Kubernetes service and ServiceEntry conflicts. Both issues are resolved in Istio 1.14.5.