ListenerClass CRD restructure

[NickLarsenNZ]

We currently have all ListenerClass spec fields at the top level. Most are passed through to the Service and most are prefixed with service while others are not.

Perhaps we should consider one of these options:

1. Prefix all fields that will be passed to Service with service.
2. Move Service related fields down to serviceOverrides
   • We need to consider if there are Service fields that should not be overridable.

Option 1 (dismissed)

apiVersion: listeners.stackable.tech/v1alpha1
kind: ListenerClass
metadata:
  name: aws-ec2-nlb-public
spec:
  # 👇 This is not passed to the Service
  preferredAddressType: HostnameConservative
  serviceType: LoadBalancer
  # 👇 prefix with `service`
  serviceLoadBalancerClass: eks.amazonaws.com/nlb
  serviceLoadBalancerAllocateNodePorts: false
  # 👆 
  serviceExternalTrafficPolicy: Local
  serviceAnotations: {}

Option 2 (dismissed)

apiVersion: listeners.stackable.tech/v1alpha1
kind: ListenerClass
metadata:
  name: aws-ec2-nlb-public
spec:
  # 👇 This remains unchanged, not passed to the Service
  preferredAddressType: HostnameConservative
  # 👇 New
  serviceOverrides:
    type: LoadBalancer
    loadBalancerClass: eks.amazonaws.com/nlb
    loadBalancerAllocateNodePorts: false
    externalTrafficPolicy: Local
    annotations: {}

Option 3 (approved)

apiVersion: listeners.stackable.tech/v1alpha1
kind: ListenerClass
metadata:
  name: aws-ec2-nlb-public
spec:
  # 👇 This remains unchanged, not passed to the Service
  preferredAddressType: HostnameConservative
  # 👇 New
  serviceOverrides:
    <service object>
    metadata:
      annotations:
    spec:
      type: LoadBalancer
      loadBalancerClass: eks.amazonaws.com/nlb
      allocateLoadBalancerNodePorts: false
      externalTrafficPolicy: Local

[sbernauer]

I really like the idea of serviceOverrides. We need to watch the CRD size and decide if we include the Service schema or not.

[sbernauer]

@siegfriedweber had a good comment:
We should put a Service object in here, and not a ServiceSpec. E.g. so that we can set annotations

[lfrancke]

I like this proposal and I agree that it should be Service and not ServiceSpec.

We regularly get requests to be able to override everything we create.
Before we do anything here I'd like to have a brief brainstorming session to see how the "override all the things"-concept could look like so we don't do something now that we might want to change in the future.

[lfrancke]

We did have the brainstorming session and added an Option #3 above.

As far as I'm concerned this can go to Voting.

[NickLarsenNZ]

Voting time

Totally not influencing any choice here, but...

• 🚀 Option 1: Keep adding fields like a pleb
• 🎉 Option 2: What was supposed to be what Option 3 is, so probably vote for that instead.
• ❤️ Option 3: Use the proper Metadata and Service Spec layout (the sane option if you were wondering)

I excluded the option for not changing because I think some change is required.