Proposal: CRD/controller to manage functions

[openfaas]

Proposal: CRD/controller to manage functions

[jgensler8]

Hey @alexellis,

I have implemented a Controller for OpenFaaS definitions: https://github.com/jgensler8/openfaas-controller

To do so, I have generated and committed a go-client library for OpenFaaS: https://github.com/jgensler8/openfaas-client-go

Definitions look like the following:

apiVersion: "jgensler8.openfaas.apiextensions.k8s.io/v1"
kind: "Function"
metadata:
  name: "samplefunction"
spec:
  service: "myservicetwo"
  image: "nginx:1.13"
  envVars: []
  envProcess: ""
  registryAuth: ""
  network: ""

As you can see, the apiversion should probably change to something more "official." Perhaps referencing other projects (like Istio) could help with deciding a proper group

In terms of using the generated go client library, I think there is some overlap with openfaas/faas#214 as the names of the CRUD functions look like SystemFunctionsPut instead of UpdateSystemFunctions or UpdateFunction

Let me know what you think of the initial design as well as moving the go-client library elsewhere.

Regards,
Jeff

[alexellis]

@stefanprodan has started to do a spike on this at https://github.com/openfaas-incubator/faas-o6s

Stefan can you update this issue with the discussion from the yesterday around versioning and migration.

@jgensler8 thanks for spending some time looking into this. Do we have you in the Slack community yet?

[jgensler8]

@alexellis I am not in the Slack Channel yet. I'll tweet or email in the next day or so.

[alexellis]

Please email [email protected] so I can get you into the community Slack. If possible it'd be great to have you two collaborating on this piece.

[alexellis]

Work is in progress on this. cc @jgensler8

[burtonr]

@stefanprodan Could you share a little about what you've done with this?
I see it's implemented on openfaas-operator here: https://github.com/openfaas-incubator/openfaas-operator/pull/8

Is there any chance of that getting ported back here?

[stefanprodan]

I would deprecate the current faas-netes code, move it to a branch and copy the openfaas-operator code into faas-netes master. The downside to this would be breaking compatibility with Kubernetes 1.7

[alexellis]

faas-netes is stable and openfaas-operator is alpha, it needs testing and exposure which we are planning to do through allowing people to install it with Helm.

This issue should stay open to track the progress of above.

[alexellis]

Ping to @jgensler8 - please could you take a look at our operator and kick the tires?

[jgensler8]

@alexellis I don't think I'll have time to look at your operator. I have explored non-Kubernetes options as the cost of hosting Kubernetes was too much for my side project.

[alexellis]

You can host on a single node VPS for less than $5/month

[alexellis]

@stefanprodan what thoughts do you have on the new operator framework/SDK via CoreOS/RedHat? Pros/cons? https://github.com/operator-framework

[stefanprodan]

I've taken a look at the RedHat Operator SDK and my conclusion is that we should stick to the current implementation based on the official Kubernetes CRD Controller. The Operator SDK is pre-alpha and lacks some features that we need such as access to k8s_client, Prometheus Integration, EventRecorder support and many more.

[alexellis]

Derek close: released as OpenFaaS Operator

[alexellis]

Derek lock