-
Notifications
You must be signed in to change notification settings - Fork 68
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
feat: refactor i2gw codes and add new features #19
Conversation
Signed-off-by: bitliu <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Xunzhuo The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
xref: #21 |
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 work on this @Xunzhuo! Some great improvements in here.
@@ -0,0 +1,119 @@ | |||
{ |
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.
Is there an easy way to generate the output files when developing these test cases?
Use: "translate", | ||
Short: "Translates Ingress resources into Gateway API resources.", | ||
Example: ` # Translate Ingress Resources into Gateway API Resources Locally. | ||
i2gw translate --file <input file> --mode local |
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.
Is this limited to a single file? If so, it seems like it would be helpful to have an option to find all Ingress manifests in a directory and covert them.
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.
It could be added later I think : )
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 think we should lean more into Unix style, and have the tool convert its arguments, with the argument list either being filenames (like i2gw translate ingress1.yaml ingress2.yaml
etc) or have i2gw translate
able to take from stdin somehow ( we could use the special filename -
like kubectl does as well).
If the output can be in a kubectl apply
-able format, then you can also make a pipe like ls ingress/*.yaml | xargs i2gw translate | kubectl apply -f -
if you want to directly apply in a more Unix-y way.
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.
The trick here is to think about how, if you had 1000 Ingress YAMLs to convert, how would you want to do it?
@@ -0,0 +1,62 @@ | |||
Gateways: |
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 think if I were using this tool I'd prefer to have output that I could translate directly to kubectl apply
, this additional structure/nesting would prevent 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.
Actually I think this is in more generic since it can be converted into a yaml or json. People can use something like jq
to parse it. Or maybe we can have an additional flag like --format
which can make the output in the kubecl apply
format(Which I think we can add them later). One reason to have a struct to store/nest these resources is that we can filter these GWAPI resources with different types like Gateway, HTTPRoute, etc.
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 think that having the objects be separate YAML documents within a single file ( that is, separated with ---
) should work just as well though, I think most of the tools will support that, and then it's also directly kubectl apply
-able.
@@ -0,0 +1,53 @@ | |||
apiVersion: networking.k8s.io/v1 |
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.
It's very common to see Ingress resources mixed in a manifest file with other resources like Services or Deployments. It seems like we should have test coverage to show what happens when that's the input.
type IngressProvider string | ||
|
||
const ( | ||
IngressNginxIngressProvider IngressProvider = "ingress-nginx" |
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 think it's reasonable to start with this since we only have one provider right now, but I'd be tempted to split this out into different files or maybe packages for each provider going forward so it was easier for individual implementations to update their own translation code without breaking others.
return nil | ||
} | ||
|
||
func (t Translator) ConstructIngresses(mode, file string) ([]networkingv1.Ingress, error) { |
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.
It would be helpful to have comments describing what this and other exported functions are doing. In this case I'd be tempted to call this ReadIngresses
because Construct
makes me think we're building new things, not just reading existing things.
} | ||
|
||
func getInputBytes(inFile string) ([]byte, error) { | ||
|
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.
} | ||
|
||
// kubernetesYAMLToResources converts a Kubernetes YAML string into Ingresses | ||
func kubernetesYAMLToResources(str string) ([]networkingv1.Ingress, error) { |
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.
func kubernetesYAMLToResources(str string) ([]networkingv1.Ingress, error) { | |
func readIngressesFromYAML(str string) ([]networkingv1.Ingress, error) { |
if err != nil { | ||
return nil, err | ||
} | ||
un := unstructured.Unstructured{Object: obj} |
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 thought there was an easier way to do this? Especially since we really only care about Ingress resources and can likely ignore anything else. Would something like this work? kubernetes/client-go#193 (comment)
Co-authored-by: Rob Scott <[email protected]>
Signed-off-by: bitliu <[email protected]>
@Xunzhuo let us know if you want to follow up on these, for now I'm going to close out in favor of more recent PRs. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
local
andremote
, to support translating Ingress from files besides from the clusters.json
andyaml
.Sub of #9
Which issue(s) this PR fixes:
xref: #21
Does this PR introduce a user-facing change?: