Feedback is welcome 😄

[thisthat]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community.
Discussions are a great place for:

• ask questions you’re wondering about,
• share ideas,
• engage with other community members,
• welcome others and are open-minded. Remember that this is a community we build together 💪

I would like to bootstrap the discussions by collecting feedback on the new Lifecycle Controller. Feel free to provide your thoughts and feedback as a comment here 🚀

[agardnerIT]

Some initial thoughts:

1. Everything definable as code. No imperative CLI commands. True GitOps ability.
2. Can we have an extensible mapping file (ConfigMap?) that maps k8s event to a function. The tool isn't opinionated to just deployment events but can react to any lifecycle event.

For example

...
// event, namespace, labels, function
CrashLoopBackOff, keptn, app=webhook-service, myCustomFunction(event)
...

3. Custom functions should not interact with tools directly but rather emit CloudEvents
4. Ability to subscribe to multiple functions for the same event (eg. two functions can fire simultaneously on the above CrashLoopBackOff example.
5. Generic function to trigger a Keptn sequence?
6. Functions can return values as finished events (a limitation of the JES currently) for example, a get-sli function can return metrics.
7. Adoption: Don't limit to certain programming languages. I assume these functions will be containerised and deployed as k8s jobs so I should be able to write in Go, Python, Javascript or anything else I choose. Forcing me to a particular language just limits the pool of contributors.

[thisthat]

Hey @agardnerIT, thank you for your suggestions! 🙌

1. We are designing the Lifecycle Controller with GitOps in mind. Everything should be configured via code.
2. That's a good suggestion, thank you! 😃
3. Could you please expand on how you envision the function execution with CloudEvents? This will help us in the designing phase :)
4. For this playground experiment, we wanted to start with one function only. The reason is to abstract away for the moment from concepts such as: sequential order or parallel, how to deal if one fails - should be both re-executed or not? We will follow up on this topic with the community to see how we should deal with all the hidden complexity 😄
5. 👍
6. That's an interesting approach! Could you please elaborate more on the use case that you have in mind?
7. I agree. We indeed want to use Jobs to abstract away dependencies and programming language

[thschue]

Hello @agardnerIT and thanks for your Feedback!

1. There is no CLI and everything is definable as code
2. Reacting on Kubernetes Events is definitely a cool thing and is taken into consideration.
3. It might be possible to issue cloud events as a task handler, but at the moment we're running functions directly
4. Agree to @thisthat
5. Could be one of the first functions :-)
6. Thought about this, nevertheless we have to find a way how to return values in Kubernetes objects (jobs). I currently thought about writing such things in the terminationLogs, additional ideas for this are very welcome ...
7. It's only a matter of maintenance ... At the moment, we're starting with a TypeScript runtime. If there are maintainers for additional runtimes, it will be no problem :-)

[agardnerIT]

I saw some pseudocode that looked like:

function doSomething(event) {
  slack.sendMessage("message here...")
}

This fundamentally goes against the tool agnostic nature of Keptn + CloudEvents. The Keptn way would be:

function doSomething(event) {
  eventBus.sendCloudEvent("sh.keptn.event.notification.triggered",....)
}

For the function maintenance, would something like Knative func work? func create -l typescript myFunction then func build, func run and func deploy.

func supports:

• Typescript
• Golang
• Python
• Quarkus
• Python
• Rust

[thschue]

1. for the lifecycle controller, cloud events might be just another way to trigger tasks. As the lifecycle controller itself has no control plane, we cannot assume that there is a message bus that could deliver cloud events. In further consequence, running functions and jobs in-cluster will keep the entry barrier for the lifecycle controller very low as the only thing you need is a Kubernetes Cluster (but no execution plane service or control plane).
2. The current Deno runtime is only a first step to get started, and I think (but that's my opinion) we should ship at least one runtime with the lifecycle controller, as this simplifies things for the end-users. Other things (as knative) might be other Task Execution Handlers in the future.

[agardnerIT]

cloud events might be just another way to trigger tasks

CloudEvents are the way tasks are triggered. The decoupling is a core benefit of Keptn, something I have been messaging for over a year. If Keptn is moving back towards directly triggering tooling, what value is this aiming to bring over existing tools like kubewatch, Brigade.sh or Argo Events? See also this project that looks related / interesting

we cannot assume that there is a message bus that could deliver cloud events

Why not? Keptn comes with an event-bus therefore it's safe to assume it's available.

Edit: Just watched the dev meeting recording and demo. Summary: Lifecycle controller can currently be thought of as a separate project to Keptn. So Thomas is correct in that is doesn't assume a control plane.