Rename `deployments` field to `components` (or something else more generic)

[pierDipi]

Problem

The current approach of defining overrides for Knative components is to define a field, called deployments like the following:

spec:
  deployments:
  - name: controller
    resources:
    - container: controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi

While most of the components in eventing and serving are using deployments, some components use StatefulSets and to have consistency across different components (even components currently unsupported by the operator) having 2 fields one for deployments and one for statefulsets will make the API harder to use.

The main reason to switch to a more generic name is that all fields in DeploymentOverride are applicable to StatefulSets or DeamonSets and users shouldn't necessarily understand which component is of which kind to use it since the override configurations will work trasparently.

The new field components might be added in v1beta1 as an additional field and then once we move to v1 we can remove the deployments field.

Persona: Which persona is this feature for?

Exit Criteria A measurable (binary) test that would indicate that the problem has been resolved.

• Rename deployments field to components (or something else more generic than deployments)
• Rename DeploymentOverride struct to ComponentOverride.

Time Estimate (optional): How many developer-days do you think this may take to resolve? 5

Additional context (optional) Add any other context about the feature request here.

[pierDipi]

@houshengbo @matzew what do you think?

[houshengbo]

So far the deployments only supports the configuration of deployment. It has not extended to other resources. There is another field named "services" already to configure all service resources.

[pierDipi]

Yes, what I'm suggesting is that it doesn't have to be that way, services are completely different so it makes sense to have a separate field.

[pierDipi]

@houshengbo I didn't get your opinion on this fully, can you expand a little bit?

[houshengbo]

The current version of the custom resources is v1beta1.

I tend NOT to rename the field name within the same version, coz it will lead to compatibility issue and more trouble to maintain. The only change we do to the CRD within the same version is to add new fields.

For later version, like v1, we can think of rename this field and extend the capability to configure deployments, statefulsets, etc.

Say if we really need to add the configuration support of statefulsets, DeamonSets, etc, in the current v1beta1 version, we probably need to add NEW fields to support them, like spec.statefulsets and spec.DeamonSets.