[Discussion] Add the ability to control concurrency of functions about openfunction

[lizzzcai]

As a temporal solution maybe, can we allow adding label and annotation to the serving.

for example:

apiVersion: core.openfunction.io/v1alpha2
kind: Function
metadata:
  name: hello-world-go
  labels:
    environment: dev
spec:
  version: "v1.0.0"
  image: "lizzzcai/sample-go-func:v0.4.0"
  imageCredentials:
    name: push-secret
  port: 8080 # default to 8080
  build:
    builder: openfunction/builder:v1
    env:
      FUNC_NAME: "HelloWorld"
      FUNC_TYPE: "http"
    srcRepo:
      url: "https://github.com/lizzzcai/openfunction-samples.git"
      sourceSubPath: "hello-world-go"
  serving:
    runtime: Knative # default to Knative
    labels:
      environment: dev
    annotations:
      # knative
      autoscaling.knative.dev/minScale: "3"
      # dapr
      dapr.io/enabled: "true"
      dapr.io/app-id: "hello-world-go"

This can help for Knative serving backend. We can use knative annotations, and even enable dapr as well. Which can probably help this issue as well: #173

Once OpenFunction has its own abstracted parameters, you can overwrite the annotation for knative serving.

[benjaminhuo]

@lizzzcai we'll add a unified param as serving top-level param to control this. Adding metadata like labels and annotations is another option, previously we have podspec as template https://github.com/OpenFunction/OpenFunction/blob/main/apis/core/v1alpha2/serving_types.go#L140 , but it doesn't contains metadata. @wanjunlei

[benjaminhuo]

#181 address this issue by adding labels/annotations to pod metadata.
We also consider adding a unified param to control the concurrency of different runtimes later.

[benjaminhuo]

Would it be appropriate to put the "hard limit" in the FAQ?

Sure, would you help to move FAQ in github to a FAQ section in https://openfunction.dev/docs/reference/ ?

[benjaminhuo]

OK, then this issue can be closed by adding FAQ for both knative and dapr in https://openfunction.dev/docs/reference/faq

[lizzzcai]

for all these configs, are you planning to expose it as it is or have the OpenFunction own-defined parameters/annotations? like:
autoscaling.openfunction.io/target: "200" or openfunction.io/app-max-concurrency: "1"

then map to different annotations based on the serving engine used by the user.

openFunction has different serving engines. The users probably don't want to know and learn what is running underneath. Maybe it will be good if OpenFunction can abstract them and provide documentation for them.

And a global Config will be very useful as well.

[benjaminhuo]

for all these configs, are you planning to expose it as it is or have the OpenFunction own-defined parameters/annotations? like: autoscaling.openfunction.io/target: "200" or openfunction.io/app-max-concurrency: "1"

then map to different annotations based on the serving engine used by the user.

openFunction has different serving engines. The users probably don't want to know and learn what is running underneath. Maybe it will be good if OpenFunction can abstract them and provide documentation for them.

And a global Config will be very useful as well.

Good Point, we'll considering this @tpiperatgod @wanjunlei

[tpiperatgod]

If it is possible to pass these parameters through as much as possible I think it is the better solution, but maybe we have to use a high-level wrapper to handle them?

I will try to make a rough option first for reference and we can also talk about this in meeting.

[benjaminhuo]

We need a proposal to add this option and a PR for that , @zhu733756 would you help on this?

[zhu733756]

Yeah.

[benjaminhuo]

Soft limit has been supported by the target annotation https://openfunction.dev/docs/concepts/function_scaling_trigger/, while hard limit is not supported yet

[tpiperatgod]

Soft limit has been supported by the target annotation https://openfunction.dev/docs/concepts/function_scaling_trigger/, while hard limit is not supported yet

Would it be appropriate to put the "hard limit" in the FAQ?

[benjaminhuo]

@tpiperatgod @wanjunlei can openfunction support adding dapr annotations mannually now?
to support https://docs.dapr.io/operations/configuration/control-concurrency/

[tpiperatgod]

@tpiperatgod @wanjunlei can openfunction support adding dapr annotations mannually now? to support https://docs.dapr.io/operations/configuration/control-concurrency/

openfunction can support this