operator: Specify CRD for API resource

LesterThomas commented 9 months ago

Description

The ODA Canvas uses the Kubernetes Operator pattern to manage components and automatically configure API Gateways/ Service Meshes / Observability systems / Identity Management Systems etc. The operator pattern includes a Custom Resource (that defines the data model schema), and a controller that that listens for updates to the custom resources and reconciles the actual state of the managed component to reflect the desired state (as defined in the spec of the custom resource).

At present, the Component resource (component.oda.tmforum.org) is well defined using a Custom Resource Definition (see Component CRD. The definition reflects the design outlined in IG1171 ODA Component Definition. The CRD includes versioning of the CRD and a webhook that automatically converts between versions. The strategy is to allow n-2 (support the current and 2 previous versions of a component). That means you can still deploy components that conform to the v1beta1 version of the Component CRD in the current Canvas (which supports v1beta3). The same is true for the controllers and other utilities - the canvas can include controllers that use previous versions of the Component API (up to n-2) which allows for an incremental development of the Canvas itself. The support for n-2 is tested as BDD Features UC016-F001-Seamless-upgrades-Installing-components-using-prev-version.feature and UC016-F002-Seamless-upgrades-Canvas-Operators-using-prev-version.feature.

As part of its operation, the Component controller creates an API resource (api.oda.tmforum.org) for each API that it wants to expose. (See use case UC002-Expose-APIs-for-Component. At present, we haven't defined a formal schema for the API resource - the current API CRD has a definition that allows any payload (using x-kubernetes-preserve-unknown-fields: true).

This issue is to implement a proper data schema for the API resource - our objective is to allow a given Canvas to deploy one of a variety of API controllers (depending on the API Gateway and/or Service Mesh used by that canvas). The definition should also implement a webhook to allow similar N-2 versioning of API resources. I propose we also rename this resource to ExposedAPI (exposedapi.oda.tmforum.org) since I believe we will need to create a Custom Resource to manage dependent APIs. We should also extend the definition to capture the requirements we would want the developers of a component to specify as part of their component definition (e.g. OAuth authentication, rate limiting etc).

LesterThomas commented 8 months ago

@OmidTahouri - this is the issue to discuss the definition of the ExposedAPI resource.

LesterThomas commented 8 months ago

I've drafted a new ExposedAPI CRD in the 163-operator-specify-crd-for-api-resource feature branch.

The CRD is at charts / oda-crds / templates / oda-exposedapi-crd.yaml

As a started, I've added two new properties:

ratelimit:
  type: integer
  description: (optional) The rate limit for the API
policytemplate:
  type: string
  description: (optional) The name of the policy template to use for the API

tmforum-oda / oda-canvas

operator: Specify CRD for API resource #163

Description