Rename generic app config to something more specific

[philipp94831]

Currently, most components use app to specify its config. We should consider renaming it to something more specific so that the purpose becomes more clear.
Suggestions:

• values for Helm (and Kubernetes? I don't even understand what the config for Kubernetes does https://github.com/bakdata/kpops/blob/main/kpops/components/base_components/kubernetes_app.py#L21)
• config for Connectors (in line with https://docs.confluent.io/platform/current/connect/references/restapi.html#get--connectors-(string-name)-config)
• ...

[raminqaf]

I don't even understand what the config for Kubernetes does

@philipp94831 model_config is Paydantic's base model field for configuring your model. The [allow_extra](https://docs.pydantic.dev/latest/api/config/#pydantic.config.ConfigDict.extra) is defined as:

Whether to ignore, allow, or forbid extra attributes during model initialization.

[disrupted]

I don't even understand what the config for Kubernetes does

@philipp94831 model_config is Paydantic's base model field for configuring your model. The [allow_extra](https://docs.pydantic.dev/latest/api/config/#pydantic.config.ConfigDict.extra) is defined as:

Whether to ignore, allow, or forbid extra attributes during model initialization.

I don't see how this is related to the issue

[philipp94831]

I linked to the wrong thing above. This is what I meant https://github.com/bakdata/kpops/blob/main/kpops/components/base_components/kubernetes_app.py#L42. Why does KubernetesApp has an app field if it is not used (or I don't see it). It makes sense to have it for HelmApp

[disrupted]

but a plain Kubernetes app (which is not managed by a Helm chart) can also have values, e.g.

kubernetes-app:
  app:  # rename: values
    labels:
      foo: foo

[philipp94831]

How are these used for deploying the app? Because there is no manifest template they are used for

[disrupted]

true, this is not implemented as of yet. So far we're only using it for the enrichment for components inheriting from KubernetesApp, e.g. HelmApp and Cleaner/Resetter. In the future we would like to support standalone KubernetesApps, i.e. deploying them using the Kubernetes API.