Michele, Two thoughts:
1) For writing a controller in Knative I recommend to choose Go instead of Rust (even when I like Rust more). With Go you can leverage the fantastic Operator SDK from Redhat which makes writing controllers fairly simple (I had my first one up and running in under an hour). Link: https://github.com/operator-framework/operator-sdk The getting started guide is a good starting point: https://github.com/operator-framework/getting-started It also addresses the lifecycle of an controller with the Lifecycle Manager: https://github.com/operator-framework/operator-lifecycle-manager (I have not yet used this myself) 2) I think we should clearly separate the Knative work from Openwhisk and stay there with a strict Scala only policy (with the existing exceptions). Introducing more languages would in my opinion lead to maintenance problems and the waste of build up skills. Regards, Martin > On 15. Jul 2019, at 11:58, Michele Sciabarra <mich...@sciabarra.com> wrote: > > Hello all, > > In my efforts to work a Kanative Whisk, I reached the point where I have a > kit with tekton-pipelines, knatve-serving building an actionlooop based > runtime. Now I need to implement a controller, in order to use the existing > wsk tooling. > > I know there is a prototype kwsk implementation made by redhat, written in > Go but looks like it is obsolete and unfinished, and to the best of my > knowledge, abandoned. > > I would like to resume the effort of writing an updated controller. I > actually already have a prototype using the Julia language. Julia is really > awesome, Python simplicity and Go speed, but I feed the community would > disagree on using Julia. Of course if I am wrong... let me know because that > would be my preferred choice. > > However, I feel that, given our Scala background, Rust would be a much > better choice for the KnativeWhisk controller. So I propose to use Rust for > the KwhiskController. > > What does the community think of the proposal? > > > -- > Michele Sciabarra > mich...@sciabarra.com
