Refactoring `func.yaml` file to follow a CRD format

[salaboy]

Currently, the func.yaml file describes a Func project and it follows its own conventions and schema for defining and validating the available configuration values.

By refactoring func.yaml to a CRD-like resource we can:

• Reuse existing Kubernetes API machinery to write & validate the configuration
• If custom metadata wants to be added to the Kubernetes resources generated by the func CLI we can follow the same principles as other Kubernetes resources do.
• On-ramp users to the Kubernetes world, there are a number of other projects following this approach like for example KinD, Keptn and Jenkins X. Func configuration files feel similar to other Kubernetes resources, which will be created by the func CLI
• It enables the idea of having a Kubernetes Controller to deal with these resources in the future, or it makes transformations easier to deal with Kubernetes tools, for example using mutation web hooks.
• By having a section for mutable fields (status), we establish a clear separation between configuration details and data is is updated by the func CLI

The following is an example of what this refactoring would look like:

apiVersion: func.knative.dev/v1alpha1 // instead of 0.19.0?
kind: Function
metadata: 
  name: level-1
  namespace: "default"
spec:
  runtime: springboot
  registry: "" // This should come from a global configuration? 
  invocation:
    format: http
  build: git
    git:
      url: https://github.com/salaboy/level-1.git
      revision: main
    builder: paketobuildpacks/builder:tiny
    builders:
      default: paketobuildpacks/builder:tiny
    buildpacks: []
    buildEnvs:
    - name: BP_NATIVE_IMAGE
       value: "true"
  template:
    spec: 
      image: salaboy/level-1/level-1:latest
      volumes: []
      env: []
      annotations: {}
      options: {}
      labels: []
      healthEndpoints:
        liveness: /health/liveness
        readiness: /health/readiness
status: // All modifications done by the CLI when updating state should go in status
  imageDigest: ""
  created: 2022-02-01T10:10:13.540854Z

@lance @evankanderson @zroubalik @matejvasek @xtreme-sameer-vohra (and community in general) feedback is highly appreciated. I've created the issue to see if we can discuss this in our weekly meeting tomorrow. Still in Draft, as I think that there are more advantages than the one listed here, wdyt?

[salaboy]

@rhuss we have discussed the multiple levels of nesting as a big issue that can bring confusion and it does complicate the configuration file. The proposed structure kept the nesting to the minimum while providing a relationship to the different phases in the lifecycle of the function. Your suggestion of including deployment details inside a run section sounds really confusing, as we have a func run command to run things locally and func deploy to run the function on a cluster. Overriding environment variables specifically for deployment can be added later on to the proposed structure. Does this make sense?

[rhuss]

@rhuss we have discussed the multiple levels of nesting as a big issue that can bring confusion and it does complicate the configuration file. The proposed structure kept the nesting to the minimum while providing a relationship to the different phases in the lifecycle of the function.

I don't agree that careful and sensible nesting is more confusing than a huge flat list, especially when the list elements are sometimes ignored, sometimes not, depending on the context (whether running in the cluster or locally). That is confusing.

Your suggestion of including deployment details inside a run section sounds really confusing, as we have a func run command to run things locally and func deploy to run the function on a cluster.

I agree that run is probably not a good name here. In retrospect, I probably wouldn't have chosen "run" and "deploy" as names for local and cluster runs, as it's not intuitive. Try to ask people that do not know functions what if they could guess what kn func run and kn func deploy would do and what they think the difference ist (maybe that would be a good question for one of the next UX interviews, in case we have the possibility to those again l;-) But it's easy to complain after the fact, so won't do that here :) But maybe we could find a different name for that top-level element? I don't care so much about the concrete name, but I definitely care about avoiding having long flat lists with many ungrouped context-sensitive elements, which is never intuitive and requires reading and memorizing the documentation.