You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order for Gateway API to release v1.0.0 we need conformance tests for all things core and extended. One extended feature available for GA is the ability to statically assign addresses to a created Gateway resource rather than allowing those IPs to be dynamically provisioned:
After this is implemented, we need to plug the upstream conformance test suite into Blixt and start running Gateway API conformance tests as a part of our CI, at least to the level of Gateway conformance for this iteration.
Acceptance Criteria
Static IP addresses from a known pool for my Service provider can be used for Gateways
Support for static IPs on Gateways depends on the Service provider in Blixt, if the underlying provider does NOT support doing this make sure the Gateway status reflects this and if the IP is removed becomes eventually consistent
The text was updated successfully, but these errors were encountered:
In order for Gateway API to release
v1.0.0
we need conformance tests for all things core and extended. One extended feature available for GA is the ability to statically assign addresses to a createdGateway
resource rather than allowing those IPs to be dynamically provisioned:kubernetes-sigs/gateway-api#2035
The purpose of this task is to implement this functionality in Blixt, which supports both kubernetes-sigs/gateway-api#2035 and #81, as well as kubernetes-sigs/gateway-api#1794 and kubernetes-sigs/gateway-api#1792.
After this is implemented, we need to plug the upstream conformance test suite into Blixt and start running Gateway API conformance tests as a part of our CI, at least to the level of
Gateway
conformance for this iteration.Acceptance Criteria
Service
provider can be used forGateways
Gateways
depends on theService
provider in Blixt, if the underlying provider does NOT support doing this make sure theGateway
status reflects this and if the IP is removed becomes eventually consistentThe text was updated successfully, but these errors were encountered: