[RA2] Decide whether to add Cluster LCM to scope

[rgstori]

ref RM ch9

currently explicitly excluded from scope

discuss whether Cluster LCM should be part of the scope, and if so, how (eg should we constrain a solution or not, to what level should we specify its properties...)
PROS: useful for operators, provides guidance to reference implementation, may help direct vendors to existing standards
CONS: no immediate impact on workloads, may constrain 

decide whether we can agree on a common starting point (eg northbound API), by taking open source specs and, if justifiable, including them in the RA2 CaaS manager requirements and specs

[pgoyal01]

@rgstori Mention of Kubernetes Clusters already exist in multiple chapters and yet we do not have any specs related to them. I don't think we need the TSC to weigh in. We are utilising a resource and its management in our document about which we have no specifications.

[CsatariGergely]

The only reference to Kubernetes Cluster LCM in RA2 is in Ch01: "- Kubernetes cluster lifecycle management: Since it is not considered to be "visible" to a CNF, it should not be included.".
I think this is a an extension of the project scope what moves the focus of the project from its original scope (ie.: decrease the integration cost of cloud infrastructures and their workloads).

[pgoyal01]

The document is not only about workloads -- if it was a lot of content can be deleted. It was also about what the operators need and guidance to them.

[rgstori]

To me, the spirit of including CaaS cluster LCM is in fact about decreasing the integration cost of cloud infrastructures: by standardising cluster LCM, an operator can reduce the costs to deploy CaaS platforms. CaaS cluster deployment is an activity where customisations should be reduced as much as possible through standardisation, and automation can be leveraged without excessive entry barriers.

Additionally, from the workloads' perspective, Operators are not deploying Cloud platforms for the sake of it: having a lower cost when deploying CaaS platforms will also have a positive impact on the workloads that are the very reason for which this infrastructure exists in the first place.

[karinesevilla]

Agree to include Kubernetes Cluster LCM and extend the initial scope of RA2.
Cluster LCM is a mandatory part of Cloud Infrastructure, and we need to provide guidance to fulfil principles and requirements such as immutable infrastructure and declarative approach mentioned in RA2 chapters 2 and 4

[petorre]

Depending on how this discussion goes, some text that @arkadykanevsky and I prepared might be good start:
[Cluster API](https://cluster-api.sigs.k8s.io/) provides declarative APIs and tooling that automate creation, configuration, and management of Kubernetes clusters. It defines common operations, provide a default implementation, and provide the ability to swap out implementations for alternative ones.

[pgoyal01]

@petorre Where do you suggest that we can add this? Also should there be a specification that leads to the use of Cluster API and maybe alternatives (not sure if there are any)? Something along the lines, "The Platform must support platform agnostic declarative APIs for automated creation, configuration, and management of Kubernetes clusters."

Some typo's corrected in the text below:
Cluster API provides declarative APIs and tooling that automates creation, configuration, and management of Kubernetes clusters. It defines common operations, provides a default implementation, and provides the ability to swap out implementations for alternative ones.

[petorre]

@petorre Where do you suggest that we can add this? Also should there be a specification that leads to the use of Cluster API and maybe alternatives (not sure if there are any)? Something along the lines, "The Platform must support platform agnostic declarative APIs for automated creation, configuration, and management of Kubernetes clusters."

@pgoyal01 : I don't have clear suggestion where this should go. I agree with above both @rgstori that this is useful (because if implemented it allows defragmentation) and @CsatariGergely that this is not in current scope (not towards onboarded application). Maybe it fits in RI2. That should be resolved first.

@petorre "Current Scope" was defined a lifetime (in technology terms) ago and maybe should be changed.