gloo icon indicating copy to clipboard operation
gloo copied to clipboard

Azure DestinationSpec for K8S Gateway API

Open DuncanDoyle opened this issue 1 year ago • 0 comments

Design and implement the DestinationSpec API for Azure Function Upstreams for K8S Gateway API.

Context

See als the parent issue for the context and motivation: https://github.com/solo-io/gloo/issues/9712

In our current implementation to support function parameters for Function Upstreams in K8S Gateway API, we use an ExtensionRef to a virtual Parameter resource to pass in, for example, the logical name of the Lambda function to call. See https://github.com/solo-io/solo-projects/issues/6160#issuecomment-2161397367, which contains the following example:

backendRefs:
    - name: azure
      namespace: gloo-system
      group: gloo.solo.io
      kind: Upstream
      filters:
        - type: ExtensionRef
          extensionRef:
            group: "gloo.solo.io"
            kind: Parameter
            name: echo

Since this is an unnamed parameter, it's quite hard to tell the intent of this configuration. I.e. what does this parameter actually configure

The Azure DestinationSpec in the Gloo Edge API has a named parameter called functionName which clearly communicates the intent of the parameter: https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/options/azure/azure.proto.sk/#destinationspec

We should support a types DestinationSpec configuration for Azure Function Upstreams in our K8S Gateway API implementation.

Note that this Azure DestinationSpec is one of the 3 types of DestinationSpecs we want to support (aws-lambda, azure and rest), and the other 2 also require support for multiple parameters. Our DestinationSpec API for K8S Gateway API must be aligned across these 3 use-cases.

Requirement

Design and implement an API for the K8S Gateway API that allows users to specify typed DestinationSpecs Azure Upstreams.

DuncanDoyle avatar Jul 24 '24 17:07 DuncanDoyle