Creating an Operator to manage function lifecycle (building, deploying and possibly invoke) #1624
Replies: 2 comments 1 reply
-
Maybe a naive question: for that operator to work where would be the source code delcared in CR? Would it be in github repository and then cloned inside operator (assuming gitub repo is public) then Or the operator maybe creating a build pipeline and triggering it to build from source code and deploy into namespace where is CR? |
Beta Was this translation helpful? Give feedback.
-
It looks like I may have duplicated your issue while creating discussions for each of the larger initiatives on our Functions Roadmap! See #2088
This is quite feasable, especially now that we have on-cluster builds.
Since the entirety of a Function's state is tracked as code, and expected to be in a repository, the only field required is the URL at which the source code can be found.
It should probably have
|
Beta Was this translation helpful? Give feedback.
-
I would like to get some inputs for the usefulness of creating an operator to manage functions lifecycle, i.e., to pretty much do what the "kn func XXX" does today. The main use case we have for that is for a multicluster setup, managed with Open Cluster Management (OCM), from where we want to be able to build, deploy and run different functions on different clusters. The idea is to trigger that through OCM ManifestWork, that then gets applied on the related managed cluster.
Thanks to having this new operator running on the managed clusters, when a CR object of this new CRD type is created, the operator does the needed actions to build and/or deploy (and perhaps and/or invoke) the function described in it.
If this is a useful first starting point, I would like to know the feasibility of this, and get some help defining the CRD fields so that they are valid for other use cases that you see fit
Beta Was this translation helpful? Give feedback.
All reactions