Currently we have two working cluster-stacks with a total of four class-addon-image-triplets (or however we want to call the folder beneath the kubernetes version)(will refer to as cia in the following sentences). I will try to summarize the current specifics of each cia below and make a proposal to consolidate them:

wooctavia/1-27:

• kube-vip and yawol as loadbalancer

yawol_flavor_id
yawol_image_id
network_id
virtual_ip
public_ip

alpha/1-27+28:

dns_nameservers
node_cidr
openstack_loadbalancer_apiserver
openstack_loadbalancer_apiserver_provider

alpha/1-29:

• image selected by version

dns_nameservers
node_cidr
openstack_loadbalancer_apiserver
openstack_loadbalancer_apiserver_provider

image version

the image version thing is easy to merge, favouring the alpha-1-29-approach.

LoadBalancer

Regarding the LoadBalancer there are some things that need to be smoothed a bit. Currently we have the following flags:

openstack_loadbalancer_apiserver
openstack_loadbalancer_apiserver_provider
yawol_flavor_id
yawol_image_id
network_id
apiserver_virtual_ip
apiserver_public_ip

We have to communicate to the user that we have two different areas for LoadBalancer settings:

• The Loadbalancer in front of the kube-apiserver for the cluster
• The Loadbalancer(s) that care about services deployed inside the cluster.

I propose to create two variables, with the following possible values

apiserver_loadbalancer: none, octavia-amphora, octavia-ovn, kube-vip
workload_loadbalancer: none, octavia-amphora, octavia-ovn, yawol

Next, i propose to
I propose to remove the variables openstack_loadbalancer_apiserver and openstack_loadbalancer_apiserver_provider

that would result in the following descriptions:

apiserver_loadbalancer: Possible values: none, octavia, ovn, kube-vip. If selecting "kube-vip you also have to provide kube_vip_network_id kube_vip_apiserver_virtual_ip ube_vip_apiserver_public_ip (insert openstack instructions to create networks and IPs here)"
workload_loadbalancer: Possible values: none, octavia, yawol (doesn't support appcreds, only user/password)
kube_vip_network_id: the network_id to be used for the kube-vip loadbalancer for the kube-apiserver. Has no effect when apiserver_loadbalancer is not set to kube-vip.
kube_vip_apiserver_virtual_ip the virtual IP to be used for the kube-vip loadbalancer for the kube-apiserver. Has no effect when apiserver_loadbalancer is not set to kube-vip.
kube_vip_apiserver_public_ip: the Public IP to be used for the kube-vip loadbalancer for the kube-apiserver. Has no effect when apiserver_loadbalancer is not set to kube-vip.
yawol_flavor_id: yawol flavor to use for yawol loadbalancer. Has no effect when workload_loadbalancer is not set to yawol
yawol_image_id: yawol image to use for yawol loadbalancer. Has no effect when workload_loadbalancer is not set to yawol
dns_nameservers: no effect when kubevip is used for apiserver_loadbalancer
node_cidr: no effect when kubevip is used for apiserver_loadbalancer

@chess-knight i need some help here, how do we deal with dns-nameservers and node_cidr? Ignore when apiserver_loadbalancer ist set to kube-vip?

Notes:

• restrict_kubeapi only applies when apiserver_loadbalancer= octavia-ovn or octavia-amphora
• kube-vip not supported on 1.29 (maybe also 1.28)
• breaking changes in capi 0.10.0

Todo List

• prefix network_id, apiserver_virtual_ip and apiserver_public_ip with kube_vip
• create all variables
• add description to variables
• Add node_cidr and dnsnameservers as patch to openstack-cluster-template
• update patches
• delete openstack_loadbalancer_apiserver and openstack_loadbalancer_apiserver_provider
• Deploy yawol when yawol flags are set
• Add docs for deploying yawol loadbalancer
• regex for loadbalancer allowed options