Allow Services and Ingresses for applications to be configurable by a wadm manifest
protochron opened this issue · 0 comments
protochron commented
wasmCloud/wadm#306 adds a new policies block which can be used to configure application-wide settings. The definition of this block can be freeform, which means that we can use them for virtually anything at an application level. This means that the operator can consume a particular set of policy blocks that we can use to define how the operator should configure Services and optionally Ingresses when an application is deployed.
This could look something like:
---
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: sample
annotations:
version: v0.0.1
description: Sample manifest that passes
spec:
policies:
- name: service
# We should have a dedicated set of types that the operator understands.
type: gateway.k8s.wasmcloud.dev/v1
properties:
port: 8080
protocol: HTTP
- name: service2
type: gateway.k8s.wasmcloud.dev/v1
properties:
port: 8081
protocol: TCP
additionalLabels: '{"test": "value"}"
Some decisions we need to make when implementing this feature:
- Should we focus only on enabling this feature with the Gateway API as outlined above, or do we need to continue to support Services?
- If we continue to support Services, should we add support for defining Ingresses?
- We currently use Services with EndpointSlices, however not all ingress controllers understand services that do not have Endpoints. Should we expose an option for that in this new way of configuring k8s Services?
- Which fields from each sort of service-type (gateway or service) do we expose? One of the main limitations inherent in the OAM draft spec for policies is that the
properties
field is a flat map of key-value string pairs. We can extend what we consume in the operator by using JSON strings similar to what many controllers in k8s do with annotations if needed, but that may not be the best option