Hi all,This is follow up results from Airship community conversation with Cluster API under kuberentes-API SIG. - Discussion Topics - [pramchan] What is the cluster-api responsibility regarding ability to update kubernetes components configuration of a running cluster. i.e. adding arguments or removing from the api server configuration. I.e. CAPBK? - [vince] CAPI aims to manage immutable infrastructure. It’s not necessarily the role of CAPI to manage running infrastructure. CAPI today can’t do an in-place upgrade on a running machine from say 1.16.2 to 1. “Replace” rather than “upgrade” - XRef Kubeadm operator KEP POC - [pramchan] Will v1alpha4 be compatible with v1alpha3? - [vince] we reserve the right to make breaking changes, we document these in the book. - [pramchan] What about semver guarantees? - [vince] CAPI follows upstream Kubernetes guarantees - https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning - [elmiko] jin relation to the notion of compatibility, breaking changes, and semver. just a warning not to read too much into the ideas expressed at semver.org in relation to the version numbers we are using. Discussion Topics Another topic of interest for OpenStack Provider was that if you have any missing variables for OpenStack ENV , please create a ticket under CAPI provider for OpenStack as listed below for v1alpha3 current cadence.https://github.com/kubernetes-sigs/cluster-api-provider-openstack/tree/maste... ThanksPrakash