docs: conceptual mapping of Keptn v1 components to KLT components

[StackScribe]

Closes #1630

We need some mapping of Keptn v1 components to KLT resources, etc. Initially, this helps us define the migration steps we document. Eventually, this will evolve into a document that helps users scope the migration and architect the environment they want when the migration is complete.

This first draft is intended as the basis of an asynchronous discussion. Meg scratched up some notes based on a few discussions. Please comment freely -- this will all be significantly rewritten before it is published for users!

[netlify]

✅ Deploy Preview for keptn-lifecycle-toolkit ready!

Name	Link
🔨 Latest commit	d29c2af
🔍 Latest deploy log	https://app.netlify.com/sites/keptn-lifecycle-toolkit/deploys/64d0e135ccb76100084ec7d5
😎 Deploy Preview	https://deploy-preview-1628--keptn-lifecycle-toolkit.netlify.app/docs/migrate/strategy
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[agardnerIT]

KLT primarily operates on Workloads (each of which has its own CRD)

Here Keptn isn't defining terms, the project is leveraging the terms defined by the Kubernetes project itself. No, the workloads do not have CRDs (CRDs are Custom resource definitions - the custom here meaning "custom to me and something non standard to Kubernetes". A Deployment is an "out of the box" Kubernetes resource definition and thus not "custom").
Response: Thanks, I cleaned up the prose a bit. I think this will become clearer when the terms are linked to other documents.

If you want to share the Keptn Metrics and evaluation resources between a large number of workloads and applications, locate them all in the same namespace
If you want to use different metrics and evaluation resources for different groups of workloads and applications, put each "group" in a separate namespace

These two bulletpoints are difficult for me to get my head around. Here you're actually attempting to give advice on how people architect or place their software. To me, that's out of scope for the Keptn project. Much more simple perhaps, just to say "Keptn Metrics and evaluation resources must exist in the same namespace as their target workloads". And leave it at that?

Response: This issue came up in a user question on slack and I tried to come up with a solution. Flo then provided a much better explanation; I replaced what I wrote with what he told the user.

project

In LTS, a project is supposed to represent an arbitrary, higher level grouping of services. It isn't necessarily an application, but then LTS doesn't have the concept of an application - so in reality, if you look at an LTS installation, a lot of the "projects" would actually be "applications". In LTS a "project" also had a 1-to-1 mapping with a Git repo - which in turn made the creation of projects-for-applications tough because not many people use mono-repo's for their applications.

KLT does not have the concept of a project. If we take the idea above of a project modelling an application, the closest analogue in KLT would be the KeptnApp.

service

This word is missing from your doc, but in LTS, there's a 1-to-many relationship between projects and services. 1 project can have many services. The intention is that a "service" models a "smaller chunk" of a project. In a micro services world, this may indeed represent a micro service. Having said that, I've worked on LTS installs where a "service" is actually a "wrapper" for "the entire public website". So it's not a strict definition (by design).

KLT does not have the concept of a service. The closest analogue would be a workload.

sequence

In LTS a sequence (as you've mentioned) is an ordered and user-defined sequence of tasks. These are defined in a file called shipyard.yaml. The shipyard controller micro service reads the shipyard file and (when the time is right) emits taskName.triggered cloud events onto the event bus. The shipyard controller will wait to receive taskName.started and a correspondingly equal number of taskName.finished events before the shipyard controller will read the next task and emit the following taskName.triggered.

In this way, with LTS it is possible to define arbitrary sequences or any tasks, at any length and also to link (or chain) sequences together to form (primitive) workflows.

These tasks can fire at any time because a user (or other system) triggers the sequence. For example, I could trigger a Keptn sequence which triggers a data encryption and backup, or a file movement over a network, or any other arbitrary activity that may or may not have anything to do with an application's lifecycle. The shipyard file is a general purpose workflow engine backed by cloud events. It is not opinionated to a tool, platform, technology or a particular "slice" of the lifecycle.

KLT does not have a shipyard.yaml file. KLT does not have a shipyard controller micro service. Tasks can be defined in KLT but they act only during the "pod scheduling" phase. There is no way to run. KLT task arbitrarily "whenever I like". KLT workloads can have multiple tasks defined (comma separated) but they run to completion, in the order they are defined only.

SLI
Nothing to add here

Integrations and services in JES: Most can be defined as tasks using the container-runtime runner
If that's the case, I'm yet to see any demonstration, documentation or proof thereof.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[odubajDT]

In the current state we still do not have a clear vision how the components from Keptn v1 will be mapped into KLT components. We need to discuss this further, implement it and afterwards prepare a documentations on how exactly it should work. Putting this PR on hold until everything is clear.

[StackScribe]

@odubajDT makes a good point -- it would be nice to go through some actual migrations before we write this guide. Alas, we are under a dictum to get something started without doing that. For now, let's record what we know as a way to help wrap peoples's heads around the paradigm shift and we'll see where it goes.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[RealAnna]

this is nice ❤️