Skip to content

v1.0.0

Compare
Choose a tag to compare
@kdorosh kdorosh released this 14 Nov 15:51

Breaking Changes

  • Rename the Gateway field tcpGateway.destinations to tcpGateway.tcpHosts in order to eliminate the duplicated field names (i.e., tcpGateway.destinations[].destination) (solo-io#1171)
  • Remove deprecated v1 Gateway in favor of v2 Gateway; rename v2 gateway resources to v1. (solo-io#1171)
  • When a Gateway has an empty httpGateway.virtualServices ref list, include all virtual services in the same namespace as the gateway. Previously the behavior was to include all virtual services in the cluster, which is unfriendly to multi-tenant setups. (solo-io#1142)
  • Move the Helm values field "installConfig.installationId" to "global.glooInstallationId" in order to better facilitate usage of the Gloo sub-chart in Gloo Enterprise (solo-io#1635)
  • Remove some deprecated APIs:
  1. Remove CorsPolicy from Gateway and Gloo VirtualHost, prefer setting CorsPolicy on VirtualHostPlugins.
  2. Remove name from gateway VirtualHost, was previously ignored.
  3. Remove bind_addr and circuit_breakers from Settings, prefer gloo.xdsBindAddr and gloo.circuitBreakers on same message. (solo-io#1171)
  • Rename all instances of plugins to options in Gloo's API. This prevents confusion as Gloo "plugins" is really an implementation detail for devs, and Gloo does not currently support dynamically-loaded plugins (aside from ExtAuth plugins).

Proto messages have been updated as such:

  1. VirtualHostPlugins -> VirtualHostOptions
  2. RoutePlugins -> RouteOptions
  3. WeightedDestinationPlugins -> WeightedDestinationOptions
  4. ListenerPlugins -> ListenerOptions
  5. HttpListenerPlugins -> HttpListenerOptions
  6. TcpListenerPlugins -> TcpListenerOptions

When referenced in yaml, each property is referenced as options under the appropriate containing resource. (solo-io#1171)

  • Update ExtAuth secret API to use strongly-typed configuration. OAuth and ApiKey secrets are no longer configured in the opaque extensions block, the same configuration lives at the top level in the api_key and oauth blocks. (solo-io#1171)
  • Refactor the Upstream API to remove the upstreamSpec field, bringing all the fields contained in upstreamSpec up one level to the top-level Upstream. (solo-io#1171)

Helm Changes

  • Add enabled to .Values.gateway.validation and .Values.gateway.certGenJob so users can disable the features without setting the root resource to nil. (solo-io#1561)
  • Allow the gateway certgen job to have a ttlSecondsAfterFinished set on it, defaulting to 60 seconds. A new Helm value "gateway.certGenJob.ttlSecondsAfterFinished" is provided to configure the value. This setting is currently in k8s Alpha (https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#ttl-mechanism-for-finished-jobs) so you may disable it entirely by setting "gateway.certGenJob.setTtlAfterFinished" to false. See https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-gates for information on the k8s feature flag corresponding to this setting ("TTLAfterFinished"). (solo-io#1631)
  • Add a Helm values field gateway.readGatewaysFromAllNamespaces. This new field defaults to false to preserve the old Gateway controller behavior, which is to read Gateway CRDs only from the namespace in which the controller is running. When the field is set to true, it will read Gateway CRDs from any of the watch namespaces. (solo-io#1489)
  • Move the Helm values field "installConfig.installationId" to "global.glooInstallationId" in order to better facilitate usage of the Gloo sub-chart in Gloo Enterprise (solo-io#1635)
  • knative helm charts use compareSemver (solo-io#1623)

New Features

  • The Gateway controller can now optionally process Gateway CRDs from anywhere in the watch namespaces, not just the namespace where the controller is running. The new setting controlling that can be found in the Gloo Settings object, at gateway.readGatewaysFromAllNamespaces. The value of this field can be configured at install time by setting the new Helm field gateway.readGatewaysFromAllNamespaces to your desired value; it defaults to false to preserve the old behavior. (solo-io#1489)
  • Adds the glooctl command "glooctl debug yaml". This command dumps a YAML manifest representing the current state of the Gloo installation running in the specified namespace. This is mainly used as a debug tool, and is not yet suitable for use as a Gloo backup tool; the dumped manifest contains resourceVersions, so you may be unable to do, for example, "glooctl debug yaml | kubectl apply -f -" if a resource has changed between the dump and the "kubectl apply". (solo-io#1650)
  • Glooctl will now print a warning if the version of the binary differs by either major or minor version from the Gloo server components. In the same message, it will also suggest a command to run to bring glooctl's version in line with the server version. (solo-io#1513)
  • Implement a utility to print snapshot content with the Secret content redacted (solo-io#1679)
  • Undeprecate Extensions (as configured on Gloo resources such as Listeners, VirtualHosts, Routes, etc.) and update documentation to explain its new purpose.

Extensions are now used for:

  • controllers, deployment pipelines, helm charts, etc. which wish to use extensions as a kind of opaque metadata. Extensions will be passed along from Gateways, VirtualServices, and Route tables to the underlying Proxy, making them useful for controllers, validation tools, etc. which interact with kubernetes yaml.
  • gRPC-based plugins which communicate with the Gloo translator out-of-process. Having extensions available enables development of out-of-process plugins without requiring recompiling & redeploying Gloo's API (solo-io#1205)

Fixes

  • Fix potential race where plugins may be called across translates invoked by the Validation server at the same time as the Translation sync. (solo-io#1616)
  • Use the installation ID set by Helm to ensure that glooctl uninstalls only resources created for the instance of Gloo being uninstalled. It does this by attempting to read the "installationId" label from the gloo pod. If the label is not found, the uninstall will fail. You can choose to proceed by passing the new --force flag to "glooctl uninstall", which will attempt to perform an uninstall that may inadvertently delete cluster-scoped resources belonging to some other installation of Gloo. (solo-io#1593)
  • Downgrade the log level from Error to Warn when gloo fails to report statistics (solo-io#1633)
  • Security Fix: Fix a bug where, when Gloo's logging level is set to Debug, we may inadvertently write the content of Secrets into the pod logs. We now print the same content into the logs, but with the Secret data redacted. (solo-io#1679)