OpenAPI to Gateway API support

[arkodg]

What would you like to be added:

Add the ability to convert OpenAPI (v2 and v3) input config into Gateway API config
e.g. https://petstore3.swagger.io

Why this is needed:
A lot of users seem to be hitting limits on the existing number of rules ( max 8)
kubernetes-sigs/gateway-api#1485
Creating a translation by the gateway api community should provide the recommended way to convert user API intent into Gateway API config, reducing the friction users are feeling today due to the limit

[arkodg]

cc @youngnick @mikemorris @guicassolato
this was discussed during one of the meetings during Kubecon EU, and everyone present seemed like a +1 for this

[guicassolato]

cc @youngnick @mikemorris @guicassolato this was discussed during one of the meetings during Kubecon EU, and everyone present seemed like a +1 for this

Nice! Thanks @arkodg!

Here are a few references of the Kuadrant feature I mentioned:

• Generate Gateway API HTTPRoute object from OpenAPI 3
• Generate Kuadrant AuthPolicy object from OpenAPI 3
• Generate Kuadrant RateLimitPolicy object from OpenAPI 3

It's all from kuadrantctl.

[LiorLieberman]

interesting. Was I in the loop as well? I cant remember. The suggestion is basically to add support very similar to what @guicassolato linked ?

@arkodg this is different than the IR state you and I discussed right?

[arkodg]

Yeah the ask here is - OpenAPI in, GatewayAPI out, to improve config intent optimization

@arkodg this is different than the IR state you and I discussed right?

yeah .... this is an internal detail to improve code and internal schema reuse

[LiorLieberman]

ack, thanks.
@guicassolato not to put you on the spot, but would you be interested in leading such contribution?

[LiorLieberman]

/cc @robscott

[guicassolato]

Hi @LiorLieberman. Absolutely! I'd be happy to. If I cannot send a PR in the next few days myself, I'll chase somebody in the Kuadrant team to do it.

Please assign me to the issue.

[guicassolato]

In time – this seems to be a feature that does not necessarily involve touching any Ingress resources. Are we sure we want it as part of ingress2gateway?

Or perhaps you're thinking OpenAPI specs stored in Ingress annotations? If not, then what? A subcommand?

Another option that comes to mind is gwctl.

[arkodg]

In time – this seems to be a feature that does not necessarily involve touching any Ingress resources. Are we sure we want it as part of ingress2gateway?

Or perhaps you're thinking OpenAPI specs stored in Ingress annotations? If not, then what? A subcommand?

Another option that comes to mind is gwctl.

@guicassolato imo its similar to the concept of provider which already exists today where provider specific resources are translated into gateway api, openapi/swagger can be treated as provider type

[guicassolato]

I was finally able to start working on this.

I've spotted a few challenges that could lead to the following limitations:

• All paths treated as exact – at most maybe assume a path that ends with a parameter could be converted to PathPrefix type
• No support for parameters (path, query, header, cookie)
• Limited support to server variables – only limited sets (enum) supported
• No support to refs ($ref)
• No support to external docs

Additionally, no support to any OpenAPI feature that would be obviously hard to translate to Gateway API resources, such as request bodies, examples, security schemes, callbacks, extensions, etc.

I also have the following open questions:

1. What shall we put in the backendRefs of the route rules?¹
2. In case we decide to print Gateway resources², what shall we put in the controllerName field?
3. When reading resources from the cluster, what kind of resources should we look for? ConfigMaps? If so, shall we establish a convention for the entry name? Or shall we support only --input_file with this provider?

@arkodg @mikemorris @LiorLieberman, I'd love to hear your thoughts.

Footnotes

1. Kuadrant defined an OAS extension for users to specify backendRefs in their docs. ↩

2. Gateway resources could be printed by reading host names and port numbers from the OpenAPI Server objects. ↩

[youngnick]

With respect to "this doesn't take Ingress config", I think that we've talked before about how, although this tool is called ingress2gateway, its intended use is "any config for inbound traffic to Gateway API", so I think the OpenAPI example is a great one.

I'm also excited for this to give some direction for folks on the right way to break up objects into HTTPRoutes.

For @guicassolato's questions:

• For backends, I think config is fine (via cmdline arg or config file or something)
• Same for controllerName, should be a required config for this provider
• No idea for the last one, sorry.

[arkodg]

thanks for working on this one @guicassolato ! hoping we can convert the shortcomings into GH issues and add support for it in the upstream Gateway API

reg 3. --input_file works, this is an offline tool so we dont need to deal with in cluster types yet, @LiorLieberman sgty ?

[LiorLieberman]

Thanks @guicassolato! Apologies for the late response, was out for a bit.
Regarding 3, the question we need to ask ourselves is whether we have cases that users have OpenAPI config in the cluster (in any form of resource). I assume no..(shout if I am wrong) and if I am correct so yeah, supporting only input-file would be the right way to go imo.

[mikemorris]

Late following up on this, but documenting for posterity and potential future improvements

No support for parameters (path, query, header, cookie)

• Query parameter filter proposed in GEP: Add support for query parameter in the HTTPRouteFilter API gateway-api#2895
• Cookie filter proposed in GEP: Add support for cookie in the HTTPRouteMatch API gateway-api#2891
• Don't we already have filters for request header match and response header?

Additionally, no support to any OpenAPI feature that would be obviously hard to translate to Gateway API resources, such as request bodies, examples, security schemes, callbacks, extensions, etc.

• Response body filter proposed in Support a ResponseBodyModifier filter gateway-api#1998, would that be helpful here?
• GEP: Gateway/HTTPRoute level authentication gateway-api#1494 may be of interest for security schemes, callbacks or extensions
• GEP: Add support for CORS gateway-api#1767 for CORS