Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update dependency kubernetes-sigs/gateway-api to v1 #159

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update dependency kubernetes-sigs/gateway-api to v1 #159

wants to merge 1 commit into from
+1 −1

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jun 4, 2024 •
edited
Loading

This PR contains the following updates:

Package Type Update Change
kubernetes-sigs/gateway-api Kustomization major v0.4.3&timeout=90s -> v1.2.0

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

kubernetes-sigs/gateway-api (kubernetes-sigs/gateway-api)

v1.2.0

Compare Source

On behalf of Kubernetes SIG Network, we are excited to announce the release of v1.2!
This release includes the graduation of 3 features to the standard channel and the introduction of 4 new features to the experimental channel, along with several improvements in many project areas.

Breaking Changes

GRPCRoute and ReferenceGrant v1alpha2 removal

As per a previous deprecation notice, in this version, both Experimental
and Standard channel CRDs will no longer serve the v1alpha2 versions
of GRPCRoute and ReferenceGrant.

Upgrades

Before upgrading to Gateway API v1.2, you'll want to confirm that any
implementations of Gateway API have been upgraded to support the v1 API
version of these resources instead of the v1alpha2 API version. Note that
even if you've been using v1 in your YAML manifests, a controller may still be
using v1alpha2 which would cause it to fail during this upgrade.

Once you've confirmed that the implementations you're relying on have upgraded
to v1, it's time to install the v1.2 CRDs. In most cases, this will work without
any additional effort.

If you ran into issues installing these CRDs, it likely means that you have
v1alpha2 in the storedVersions of one or both of these CRDs. This field is
used to indicate which API versions have ever been used to persist one of these
resources. Unfortunately, this field is not automatically pruned. To check these
values, you can run the following commands:

kubectl get crd grpcroutes.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"
kubectl get crd referencegrants.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"

If either of these return a list that includes "v1alpha2", it means that we need
to manually remove that version from storedVersions.

Before doing that, it would be good to ensure that all your ReferenceGrants and
GRPCRoutes have been updated to the latest storage version:

crds=("GRPCRoutes" "ReferenceGrants")

for crd in "${crds[@​]}"; do
  output=$(kubectl get "${crd}" -A -o json)

  echo "$output" | jq -c '.items[]' | while IFS= read -r resource; do
    namespace=$(echo "$resource" | jq -r '.metadata.namespace')
    name=$(echo "$resource" | jq -r '.metadata.name')
    kubectl patch "${crd}" "${name}" -n "${namespace}" --type='json' -p='[{"op": "replace", "path": "/metadata/annotations/migration-time", "value": "'"$(date +%Y-%m-%dT%H:%M:%S)"'" }]'
  done
done

Now that all your ReferenceGrant and GRPCRoute resources have been updated to
use the latest storage version, you can patch the ReferenceGrant and GRPCRoute
CRDs:

kubectl patch customresourcedefinitions referencegrants.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'
kubectl patch customresourcedefinitions grpcroutes.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1"]}}'

With these steps complete, upgrading to the latest GRPCRoute and ReferenceGrant
should work well now.

Experimental Channel: GatewayClass Supported Features

The Experimental supportedFeatures field in GatewayClass status has changed
from being a list of strings to being a list of objects/structs with a name
field.

This is to allow adding in extra information to each entry at a later date.

Relevant PRs:

Changes since v1.2.0-rc2

There was one small change since RC2 - the Gateway Infrastructure conformance
test has been marked as provisional as we're not sure that the same-namespace
requirement imposed by this test is necessary. #​3373

Release Cycle changes

This was our first release using a new release
cycle that is
meant to make Gateway API releases more frequent and predictable.

There are now four phases:

  • Scoping: 4-6 weeks, where the maintainers and community determine the set
    of features we want to include in the release. A key deliverable here is
    ensuring that the Experimental channel does not get any bigger than it already
    is; we want to ensure that features make their way to Standard or are removed.
  • GEP Iteration and Review: 5-7 weeks, where we work to update GEPs, and
    solidify and meet graduation criteria for in-scope GEPs.
  • API Refinement and Documentation: 3-5 weeks, where we translate proposed
    changes from GEPs into changes to both the API specification and
    documentation.
  • SIG-Network Review and Release Candidates: 2-4 weeks, where we perform our
    required upstream reviews, get any further required changes in, and release
    our release candidates so that implementations can get started with work on
    the new features asap.

For all the detail about this, please see the Release Cycle
docs.

Relevant PRs:

Standard Channel Additions and Changes

The Standard channel is Gateway API's set of maximally-stable install files.
Only features with the best testing and support are added to the standard
channel. This channel should be considered GA or stable, and future changes will
be fully backwards compatible.

Infrastructure Labels and Annotations 🎉

GEP-1867 added an
infrastructure stanza to Gateway objects that is intended to carry
infrastructure configuration specific to that Gateway object.

GEP-1762 adds a section for
labels and annotations to this stanza that specifies labels and annotations
to be annotated to all resources created to fulfill that Gateway request.

This feature can be used to affect the labels and annotations created on
LoadBalancer Services by in-cluster implementations to fulfill the Gateway
contract or by Cloud Load Balancing resources created by Cloud Providers.

This feature has graduated to Standard and is now considered GA or Stable.

This feature's name for conformance tests and GatewayClass status reporting is
GatewayInfrastructurePropagation.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

HTTPRoute Timeouts and Durations 🎉

The HTTPRoute Timeouts field on Route Rules has graduated to Standard and is
now considered GA or Stable.

This field allows you to configure overall Request Timeouts as well as Backend
Request Timeouts. For more information, refer to GEP
1742.

The relevant feature names this for conformance tests and GatewayClass status
reporting are:

  • HTTPRouteRequestTimeout for httproute.spec.rules[].timeouts.request
  • HTTPRouteBackendTimeout for httproute.spec.rules[].timeouts.backendRequest

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

BackendProtocol Support 🎉

The previous coordinated work across both Gateway API and upstream Kubernetes
which defined 3 new values for the AppProtocol field on Service Ports has
graduated to Standard and is now considered GA or Stable.

The values are:

  • kubernetes.io/h2c - HTTP/2 over cleartext as described in
    RFC7540
  • kubernetes.io/ws - WebSocket over cleartext as described in
    RFC6445
  • kubernetes.io/wss - WebSocket over TLS as described in
    RFC6455

These can now be used with Gateway API to describe the protocol to use for
connections to Kubernetes Services. For more information, refer to GEP
1911.

The relevant feature names this for conformance tests and GatewayClass status
reporting are:

  • HTTPRouteBackendProtocolH2C for H2C support, when
    service.spec.ports[].appProtocol is kubernetes.io/h2c.
  • HTTPRouteBackendProtocolWebSocket for Websocket support, when
    service.spec.ports[].appProtocol is kubernetes.io/ws or
    kubernetes.io/wss.

This feature's status is Extended, meaning that it is optional for
implementations to support. If you're using Experimental Channel, you can refer
to the supportedFeatures field in the status of any GatewayClass.

Relevant PRs:

  • Backend Protocol Selection is no longer experimental and is now part of
    HTTPRoute Extended Conformance by @​dprotaso in
    #​3108
Other Standard channel changes

Experimental Channel Additions and Changes

The Experimental Channel is Gateway API's channel for testing out changes and
gaining confidence with them before allowing them to go to Standard.

This channel may include features that are changed or removed later!

HTTPRoute Retry support

GEP-1731 described how to add
configuration of retries on HTTPRoute objects, and in this release, this change
has moved to Experimental.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental amd should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance tests available for this feature as
yet, please see your implementation's documentation to see if it is supported.

Relevant PRs:

  • Adds support for configuring retries in HTTPRoute by @​mikemorris in
    #​3301
  • Adds retry stanza within HTTPRouteRule to configure retrying unsuccessful
    requests to backends before sending a response to a client by @​mikemorris in
    #​3199
Percentage-based request mirroring

The existing Request Mirroring feature has been enhanced by allowing users to
specify a percentage of requests they'd like mirrored. These changes are
described in GEP-3171.

Please see the GEP reference document or the API reference for the details.

This feature has graduated to Experimental amd should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance tests available for this feature as
yet, please see your implementation's documentation to see if it is supported.

Relevant PRs:

Improvements to backend TLS configuration

Some changes have been made to Gateway API's support for configuring TLS
connections between the Gateway and backends.

Gateway has a new Experimental field that contains configuration for the client
certificate Gateways should use when connecting to Backends.

The existing BackendTLSPolicy object has had additions as well:

  • Ability to specify SANs on BackendTLSPolicy
  • Add TLS options to BackendTLSPolicy to mirror TLS config on Gateways

See GEP-3155 for all the
details.

This feature has graduated to Experimental amd should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance tests available for this feature as
yet, please see your implementation's documentation to see if it is supported.

Relevant PRs:

Named Route Rules

All Route Rule types (GRPCRouteRule, HTTPRouteRule, TCPRouteRule, TLSRouteRule
and UDPRouteRule) have had a new, optional name field to support referencing
individual rules by name.

This name, if present, may be used in status and logging to indicate which
route rule is being referenced in messages in a more readable way than an array
index.

This feature has graduated to Experimental amd should now be used for testing
and verification purposes only. Experimental features may be changed or removed
in a future version.

This feature does not currently have a feature name defined.

This feature's status is Extended, meaning that it is optional for
implementations to support.

As there is no feature name or conformance tests available for this feature as
yet, please see your implementation's documentation to see if it is supported.

Relevant PRs:

Other specification changes

Leadership changes

In this release timeframe, Gateway API has been working on building our
contributor pool and promoting more contributors up our contributor ladder.

Congratulations to @​mlavacca on being promoted into the core Gateway API
maintainer team!

Thanks to @​keithmattix for all your work as one of the GAMMA leads, and
congratulations to @​mikemorris on being promoted into the GAMMA lead team.

We've added two new GEP Reviewers: @​kflynn and @​arkodg

Also promoted in the conformance team:

Last but most certainly not least, @​guicassolato has become a reviewer for
gwctl.

Congratulations to everyone on the promotions, and thanks for your continued
contributions to the Gateway API community!

Relevant PRs:

Testing

  • Features have been re-arranged to a struct containing metadata and feature
    Name. The API Channel has been set as a field for such a struct in
    #​3287
  • Exposing grpc client interface as a option in the conformance suite in
    #​3095

gwctl

In this release, gwctl is moving to a separate repo:
kubernetes-sigs/gwctl. This will
enable a more flexible and independent release process. Significant new updates
are coming to gwctl, follow the new repo for the latest updates on that project.

Although these changes won't be part of Gateway API v1.2 and will instead be
part of the separate gwctl release, we're noting them as they were merged while
the project was part of this repo:

Documentation Changes

Testing and Conformance changes

New Contributors

Dependencies

Added
  • cel.dev/expr: v0.15.0
  • github.com/planetscale/vtprotobuf:
    0393e58
Changed
  • cloud.google.com/go/compute/metadata: v0.2.3 → v0.3.0
  • github.com/cespare/xxhash/v2: v2.2.0 →
    v2.3.0
  • github.com/cncf/xds/go: 0fa0005 →
    555b57e
  • github.com/envoyproxy/go-control-plane: v0.12.0 →
    1eb8caa
  • github.com/golang/glog: v1.2.0 →
    v1.2.1
  • github.com/miekg/dns: v1.1.58 →
    v1.1.62
  • golang.org/x/crypto: v0.22.0 → v0.26.0
  • golang.org/x/mod: v0.17.0 → v0.18.0
  • golang.org/x/net: v0.24.0 → v0.28.0
  • golang.org/x/oauth2: v0.19.0 → v0.21.0
  • golang.org/x/sync: v0.7.0 → v0.8.0
  • golang.org/x/sys: v0.19.0 → v0.23.0
  • golang.org/x/telemetry: f48c80b → bda5523
  • golang.org/x/term: v0.19.0 → v0.23.0
  • golang.org/x/text: v0.14.0 → v0.17.0
  • golang.org/x/tools: v0.20.0 → v0.22.0
  • google.golang.org/appengine: v1.6.8 → v1.6.7
  • google.golang.org/genproto/googleapis/api: 6ceb2ff → ef581f9
  • google.golang.org/genproto/googleapis/rpc: 6ceb2ff → ef581f9
  • google.golang.org/genproto: 6ceb2ff → f966b18
  • google.golang.org/grpc/cmd/protoc-gen-go-grpc: v1.3.0 → v1.5.1
  • google.golang.org/grpc: v1.63.2 → v1.66.2
  • google.golang.org/protobuf: v1.33.0 → v1.34.2
  • k8s.io/api: v0.30.0 → v0.31.1
  • k8s.io/apiextensions-apiserver: v0.30.0 → v0.31.1
  • k8s.io/apimachinery: v0.30.0 → v0.31.1
  • k8s.io/client-go: v0.30.0 → v0.31.1
  • k8s.io/code-generator: v0.30.0 → v0.31.1
Removed
  • cloud.google.com/go/compute: v1.24.0

v1.1.0

Compare Source

v1.1.0

On behalf of Kubernetes SIG Network, we are pleased to announce the v1.1 release!
This release includes the graduation of several features to GA, including both
GRPCRoute and Service Mesh. We are also introducing several new experimental
features, including Session Persistence and Gateway Client Cert Verification.

The following represents the changes since v1.0.0:

Standard Channel

GRPCRoute has Graduated to GA 🎉

GRPCRoute has graduated to GA (v1) and is now part of the Standard Channel. If
you are already using the experimental version GRPCRoute, we recommend holding
off on upgrading to the standard channel version of GRPCRoute until the
controllers you're using have been updated to support GRPCRoute v1. Until then,
it is safe to upgrade to the experimental channel version of GRPCRoute in v1.1
that includes both v1alpha2 and v1 API versions.

Leading Contributor: @​gnossen

Service Mesh Support has Graduated to GA 🎉

The standard for using Gateway API for Mesh has formally graduated to GA (v1)
and is now part of the Standard Channel.

Service mesh support in Gateway API allows service mesh users to use the same
API to manage ingress traffic and mesh traffic, reusing the same policy and
routing interfaces. In Gateway API v1.1, routes (such as HTTPRoute) can now have
a Service as a parentRef, to control how traffic to specific services
behave. For more information, read the service
mesh documentation or see the list of
implementations.

Leading Contributors: @​howardjohn, @​keithmattix, @​kflynn, @​mikemorris

Conformance Profiles and Reports

The Conformance Reports API and the corresponding test suite have been graduated
to GA. The Conformance report API has been expanded with the mode field
(intended to specify the working mode of the implementation), and the
gatewayAPIChannel (standard or experimental). The gatewayAPIVersion and
gatewayAPIChannel are now filled in automatically by the suite machinery,
along with a brief description of the testing outcome. The Reports have been
reorganized in a more structured way, and the implementations can now add
information on how the tests have been run and provide reproduction steps.

Leading Contributors: @​mlavacca, @​shaneutt

ParentRef Port field Graduated to GA

The port field in ParentRefs has graduated to GA (v1) and is now part of the
Standard Channel. You can use the port field to attach resources to Gateways,
Services, or other parent resources. For example, you can attach an HTTPRoute to
one or more specific Listeners of a Gateway based on the Listener port,
instead of name field.

Leading Contributor: @​frankbu

Experimental Channel

Session Persistence + BackendLBPolicy

Session Persistence is being introduced to Gateway API via a new policy
(BackendLBPolicy) for Service-level configuration and as fields within HTTPRoute
and GRPCRoute for Route-level configuration. The BackendLBPolicy and Route-level
APIs provide the same session persistence configuration, including session
timeouts, session name, session type, and cookie lifetime type.

Leading Contributors: @​gcs278, @​ginayeh

Gateway Client Cert Verification

Gateways can now configure client cert verification for each Gateway Listener by
introducing a new field frontendValidation field within tls. This field
supports configuring a list of CA Certificates that can be used as a trust
anchor to validate the certificates presented by the client.

Leading Contributors: @​arkodg

BackendTLSPolicy

As part of a broader goal of making our TLS terminology more consistent
throughout the API, we've introduced some breaking changes to BackendTLSPolicy.
This has resulted in a new API version (v1alpha3) and will require any existing
users of this policy to uninstall the v1alpha2 version before installing this
newer version.

Any references to v1alpha2 BackendTLSPolicy fields will need to be updated.
Specific changes include:

  • the targetRef field is now a targetRefs list and these references no
    longer include a namespace field.
  • the tls field has been renamed to validation
  • the caCertRefs field has been renamed to caCertificateRefs
  • the wellKnownCACerts field has been renamed to wellKnownCACertificates

Leading Contributors: @​candita

Gateway Params

Gateways now feature a new field that allows references to
implementation-specific parameters, similar to GatewayClass.

Leading Contributors: @​howardjohn

Everything Else

gwctl
Validation Changes
  • TLS Configuration is no longer required on Gateway Listeners to enable more
    flexible TLS configuration. (#​2721, @​robscott)
Conformance Tests
  • Conformance Profiles have been renamed and a new Mesh-GRPC profile has been
    added (#​3019, @​mlavacca):
    • HTTP -> Gateway-HTTP
    • GRPC -> Gateway-GRPC
    • TLS -> Gateway-TLS
    • Mesh -> Mesh-HTTP
  • Fixed GatewayWithAttachedRoutes conformance test to not check that the
    HTTPRoute status includes an "Accepted: False" condition because this is not
    required by the specification. (#​2548, @​frankbu)
  • A new comparison view has been added to our documentation that shows the
    extended features supported by every implementation that has submitted a
    conformance report (#​2874, @​xtineskim)
  • Added SupportMeshConsumerRoute and SupportMeshClusterIPMatching supported
    features to more clearly communicate the purpose of existing Mesh conformance
    tests (#​3035, @​howardjohn)
  • Add conformance test for HTTP listener isolation (#​3047, @​arkodg, @​pleshakov)
Dependencies
Cleanup
  • The validating webhook has been removed. CEL validation is now built-in to
    CRDs and replaces the webhook. (#​2595, @​robscott)
  • BackendTLSPolicy WellKnownCACerts field has been updated to
    implementation-specific support (#​2741, @​sunjayBhatia)
  • Clarify policy attachment by two of the same policy types when using section
    names. (#​2442, @​maleck13)
  • Remove v1alpha2 directory from docs: (#​2965, @​robscott)

v1.0.0

Compare Source

On behalf of Kubernetes SIG Network, we are pleased to announce the v1.0 release!
This release marks a huge milestone for this project. Several key APIs are
graduating to GA (generally available), while other significant features have
been added to the Experimental channel.

It's been four years since this project began, and we would never have gotten
here without the support of a dedicated and active community. The maintainers
would like to thanks everyone who's contributed to Gateway API, whether in the
form of commits to the repo, discussion, ideas, or general support. We literally
couldn't have gotten this far without you.

This project is nowhere near finished, as you can see from the large amount of
features being added into the Experimental Channel. With such a big set of
things still to do, contributors and contributions are more vital than ever.
Please feel welcome to join our community!!

Gateway, GatewayClass, and HTTPRoute are GA 🎉

Gateway, GatewayClass, and HTTPRoute have all graduated to GA with a v1 API
version. Although these APIs will continue to grow with future additions, the
versions of these resources available via the Standard Channel are stable and
recommended for use in production. Many implementations are fully passing
conformance tests that cover the functionality of each of these resources. These
APIs are graduating to GA with only minor spec clarifications since the v0.8.0
release.

CEL Migration

Starting in v0.8.0, Gateway API CRDs now include CEL validation. In this release
the validating webhook is no longer bundled with CRD installation. Instead we
include a separate webhook-install.yaml file as part of the release artifacts.

If you're running Kubernetes 1.25+, we do not recommend installing the webhook
and additionally suggest that you uninstall any previously installed versions of
the webhook.

If you're still running Kubernetes 1.23 or 1.24, we recommend installing the
webhook until you can upgrade to Kubernetes 1.25 or newer.

New Experimental Features

There are several exciting new experimental features in this release:

BackendTLSPolicy

A new BackendTLSPolicy resource has been introduced for configuring TLS
connections from Gateways to Backends. This allows you to configure the Gateway
to validate the certificates served by Backends. For more information, refer to
GEP 1897.

Primary Author: @​candita

HTTPRoute Timeouts

HTTPRoute has a new Timeouts field on Route Rules. This allows you to
configure overall Request Timeouts as well as Backend Request Timeouts. For more
information, refer to GEP 1742.

Primary Authors: @​frankbu, @​SRodi

Gateway Infrastructure Labels

Gateway has a new Infrastructure field that allows you to specify Labels or
Annotations that you'd like to be propagated to each resource generated for a
Gateway. For example, these labels and annotations may be copied to Services and
Deployments provisioned for in-cluster Gateways, or to other
implementation-specific resources, such as Cloud Load Balancers. For more
information, refer to GEP 1762.

Primary Author: @​howardjohn

WebSockets, HTTP/2, and More

Some coordinated work across both Gateway API and upstream Kubernetes has
defined 3 new values for the AppProtocol field on Service Ports:

  • kubernetes.io/h2c - HTTP/2 over cleartext as described in
    RFC7540
  • kubernetes.io/ws - WebSocket over cleartext as described in
    RFC6445
  • kubernetes.io/wss - WebSocket over TLS as described in
    RFC6455

These can now be used with Gateway API to describe the protocol to use for
connections to Kubernetes Services. For more information, refer to GEP 1911.

A new CLI tool: gwctl

An experimental new CLI tool and kubectl plugin, gwctl aims to improve the UX
when interacting with Gateway API. Initially it is focused on Policy Attachment,
making it easier to understand which policies are available in a cluster, and
which have been applied. In future releases, we hope to expand the scope of this
tool to provide more detailed responses when getting and describing Gateway API
resources. Note that this tool is still in very early stages and it's very
likely that future releases will include breaking changes for gwctl. For more
information, refer to the gwctl Readme.

Primary Author: @​gauravkghildiyal

Everything Else

Of course there's a lot more in this release:

Spec Clarifications
  • Clarify that the Gateway Listener status AttachedRoutes field is a count of
    the number of Routes associated with a Listener regardless of Gateway or Route
    status. (#​2396, @​sunjayBhatia)
  • Gateway: A new concept called "Listener Isolation" has been introduced to
    describe the recommendation that at most one Listener matches a request, and
    only Routes attached to that Listener are used for routing. (#​2465, @​robscott)
  • Experimental Channel: For ParentRefs to be considered distinct, they either
    both need to specify a distinct SectionName, both need to specify a distinct
    Port, or both. (#​2433, @​robscott)
  • Updated rules about Listener uniqueness to use the term distinct (#​2436,
    @​youngnick)
Status
  • GatewayClass Status: A new experimental supportedFeatures field has been
    added. Implementations should populate this with the features they support.
    (#​2461, @​Liorlieberman, @​robscott)
  • GatewayClass Status: A new SupportedVersion condition has been added that MUST
    be set when a GatewayClass is accepted. (#​2384, @​robscott)
  • Route Status: A new "PartiallyInvalid" condition has been added for all Route
    types. This condition also includes guidance for how partially invalid states
    should be handled with Gateway API. (#​2429, @​robscott)
  • The condition reason GatewayReasonUnsupportedAddress for Accepted now ONLY
    applies when an address type is provided for a Gateway which it does not
    support.
    (#​2412 @​shaneutt)
  • The condition reason GatewayReasonAddressNotAssigned for Programmed now
    ONLY applies to problems with dynamic address allocation.
    (#​2412 @​shaneutt)
  • The condition reason GatewayReasonAddressNotUsable for Programmed has been
    added to deal with situations where a static address has been provided for a
    Gateway which is of a supported type, and is syntactically valid, but for some
    reason it can not be used for this Gateway (e.g. the address is already in use
    on the network).
    (#​2412 @​shaneutt)
Documentation
  • A guide for Gateway API implementers is now included in the specification.
    (#​2454, @​youngnick)
  • Gateway API versioning will continue to rely

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/kubernetes-sigs-gateway-api-1.x branch from f6c9a67 to d2ada3a Compare October 3, 2024 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants