KEP 88: Lifecycle Toolkit - Adding Instances to KeptnApp

[thschue]

Signed-off-by: Thomas Schuetz [email protected]

[thisthat]

I would also add the propagation of this info into the span via OTel attribute

Suggested change

	- Properties of an instance are defined in the `KeptnApp` resource
	- Properties of an instance are defined in the `KeptnApp` resource
	- Properties of an instance are stored as attributes in the generated Spans

[thisthat]

Suggested change

	The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single".
	The `instance` property is used to specify the application's current instance. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single".

[thisthat]

I would suggest another name as default:

Suggested change

	The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single".
	The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "main".

Suggested change

	The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single".
	The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "default".

[thisthat]

This schema would require having the same KeptnApp with the instances structure across (potentially) multiple repositories. The benefit of this proposal is that we have a complete overview of the instances' tree.
I suggest only storing the partial view in each KeptnApp, i.e., the next successors of the current instance. This way, if we want to add a successor to, let's say, production, we don't need to change the KeptnApp of dev, staging, etc.
As a drawback, this won't allow a complete overview in the KeptnApp definition and push this into the Observability platform via trace.

[malon875875]

• An instance has to be specified on the workload and application level - agreed
  • Therefore KeptnApp will contain the information about the instance: dev - successor staging; staging - successor production….
• For the reposecret, I am thinking we could use Sealed Secrets
• Can Keptn LCT manage multiple instances across clusters k8-cluster-A.stage-dev -> k8-cluster-B.stage-test ?

[thschue]

• An instance has to be specified on the workload and application level - agreed

  • Therefore KeptnApp will contain the information about the instance: dev - successor staging; staging - successor production….

• For the reposecret, I am thinking we could use Sealed Secrets

• Can Keptn LCT manage multiple instances across clusters k8-cluster-A.stage-dev -> k8-cluster-B.stage-test ?

Hello and thank you for your comments!

• The KeptnApp would have all information needed to promote this through the stages
• Although it might not be the best idea to introduce a dependency to external/sealed secrets in keptn, I think this might be a good thing to document as soon as the feature is available :-)
• The management of multiple instances depends on the tasks which are using the structure which is defined here. This EP introduces the CRD changes needed to support multi-instance operations. The implementation of the promotion itself will be only a KeptnTask ... In my mind, this is possible as the promotion should happen via git (at least in a GitOps setup) and this is more or less independent on where the clusters are

[malon875875]

+1
I would love to see this PR implemented within the Keptn Roadmap

[thisthat]

TC discussion: here we could use secretName and secretKey to fetch a K8s secret.