-
Notifications
You must be signed in to change notification settings - Fork 67
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.
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
Create IR struct to hold specs for extension features. #185
Conversation
/assign @LiorLieberman |
/assign @arkodg |
/assign @robscott |
pkg/i2gw/provider.go
Outdated
GatewayExtensions map[types.NamespacedName]unstructured.Unstructured | ||
} | ||
|
||
// IR contains all Gateway-API objects, and Intermediate Representation(IR) to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious what's going to happen to the GatewayResources
struct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldnt the IR
replace it ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IR and Gateway Resources are for different translation purpuse. What I have in mind is:
A pool of resources
-------> Ingress + Ingress extension (By input provider reader)
-------> IR, or Gateway/HTTPRoute context(By input provider converter)
-------> Gateway + Gateway extension(By output provider extension converter)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's say we are doing translation of enableHTTPSRedirect feature, we will have:
type GceGatewayIR struct {
EnableHTTPSRedirect bool
}
type GceHTTPRouteIR struct {
EnableHTTPSRedirect bool
}
since HTTPS Redirect is supported by modifying the Gateway with an additional HTTPRoute to redirect HTTP traffics.
And during translation, what would happen is:
Ingress+Ingress extension
--->IR.GceGatewayIR.EnableHTTPSRedirect=true, IR.GceHTTPRouteIR.EnableHTTPSRedirect=true(by reading corresponding Ingress extension)
--->Gateway with additional HTTPRoute
Gateway extensions will be translated in a similar manner.
/cc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we see one feature that will work with the IR, ideally in this PR as a different commit, so we can look at these independently (and we wont squash the PR when we merge, to keep the separation)?
pkg/i2gw/ingress2gateway.go
Outdated
} | ||
|
||
func mergeGateways(gatewaResources []GatewayResources) (map[types.NamespacedName]gatewayv1.Gateway, field.ErrorList) { | ||
newGateways := map[types.NamespacedName]gatewayv1.Gateway{} | ||
func mergeGateways(irs []IR) (map[types.NamespacedName]GatewayContext, field.ErrorList) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you move to merge GatewayContext and not just gateways, do we need to change this function to also merge the IR fields within the gatewayContexts?
Similar comment for HTTPRouteContext
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated for GatewayContext. We don't currently perform any operations on HTTPRouteContext other than putting them together. There is no merge on HTTPRoutes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before, we had MergeGatewayResources
, right?
This would have merged anything under GatewayResources, including Gateways, GatewayRoutes, HTTPRoutes, etc. (we can see this here on the left panel)
My question is how maps.Copy(mergedIRs.HTTPRoutes, gr.HTTPRoutes)
would work given that HTTPRouteContext has nested HTTPRouteIR field with its own nested fields.
Maybe maps.copy is enough for us, idk.. but something to check, I am not sure it will work out of the box
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They should work. I've tried to run tests on functions using this helper, and they passed with expected merged results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well thats because you have nothing on the http IR yet. similarly to the logic you employ for the GatewayIR merging in db03324 you would have to add logic to merge the HTTPIRs and ServiceIR, maps.copy() would not cover that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the great work on this @sawsa307! Mostly focused on GCP section with this review
backendPolicy := gkegatewayv1.GCPBackendPolicy{ | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Namespace: serviceNamespacedName.Namespace, | ||
Name: serviceNamespacedName.Name + "-GCPBackendPolicy", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite sure if we have prior art here, but since this could at least theoretically overwrite existing config in a cluster, it might be safer to use GenerateName
instead of Name
. On the other hand, that would mean that every time this manifest was applied, you'd get a new GCPBackendPolicy.
cc @LiorLieberman @levikobi for any additional perspective on which is the least bad approach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see we are hand-crafting names for translated Gateway and HTTPRoute based on the ingress name and port, which is why I went ahead and generate a name by appending a suffix, given we can only attach one GCPBackendPolicy to a k8s Service. Definitely would like more suggestions here on the naming schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair, maybe just remove the -GCPBackendPolicy
suffix as that's already implied by the type of resource it is.
pkg/i2gw/ingress2gateway.go
Outdated
} | ||
|
||
func mergeGateways(gatewaResources []GatewayResources) (map[types.NamespacedName]gatewayv1.Gateway, field.ErrorList) { | ||
newGateways := map[types.NamespacedName]gatewayv1.Gateway{} | ||
func mergeGateways(irs []IR) (map[types.NamespacedName]GatewayContext, field.ErrorList) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before, we had MergeGatewayResources
, right?
This would have merged anything under GatewayResources, including Gateways, GatewayRoutes, HTTPRoutes, etc. (we can see this here on the left panel)
My question is how maps.Copy(mergedIRs.HTTPRoutes, gr.HTTPRoutes)
would work given that HTTPRouteContext has nested HTTPRouteIR field with its own nested fields.
Maybe maps.copy is enough for us, idk.. but something to check, I am not sure it will work out of the box
providerGatewayResources, conversionErrs := provider.ToGatewayAPI() | ||
ir, conversionErrs := provider.ToIR() | ||
errs = append(errs, conversionErrs...) | ||
providerGatewayResources, conversionErrs := provider.ToGatewayResources(ir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
anchor
Discussed with Lior, since this PR is getting too big, will separate the logic into individual PRs. #188 will be the new PR to include definitions of IRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @sawsa307! This all LGTM, left a few nits but nothing blocking.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott, sawsa307 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* Create IR struct on Gateway, HTTPRoute, and Service to hold extensions. * Add merge functions for GceGatewayIR. * Add TODO and links to existing ingress2gateway issue.
* Add BackendConfig to resource_reader. * go.mod requires go 1.22.4, while golangci-lint 1.55.2 is built on go 1.21. This would cause an issue to load go package. "go.mod requires go >= 1.22.1 (running go 1.22.0; GOTOOLCHAIN=local)" * Thus, we need to update to the latest goclint-ci version.
* Providers now should implement ResourcesToIRConverter interface and IRToGatewayAPIConverter interface.
Closing in favor of #188. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Add structures needed to support translation of extension features.
Which issue(s) this PR fixes:
Fixes #125
Does this PR introduce a user-facing change?: