identifying resources representing external services

[christianvogt]

The label app.kubernetes.io/component=external-service should be applied to a CR to identify it as an external-service.
Can we add the external-service label to the managed kafka connection and other resources like it in the future?

cc @wtrocki

[wtrocki]

@rkpattnaik780 @secondsun We have to do this at the earliest convenience, but before I'm looking for feedback.
We can apply this label:

1. When creating Kafka and Registry resources. This means CLI, Console UI and user examples will need to have this label on creation.
2. We can enforce this label by applying it when processing resources by the operator.

Approach nr1 requires changes in 3 different projects etc.

We already have some labels done (I assume that is from client side):

app-services-operator/examples/crs/KafkaConnection.yml

Lines 7 to 8 in c0618d4

	app.kubernetes.io/component: external-service
	app.kubernetes.io/managed-by: rhoas

[wtrocki]

This is going to be done in the current sprint timeline.

[secondsun]

Quick update.

The correct way to implement this feature in the operator is to create a mutating admission webhook. Doing this involves creating a container that provides an HTTP server which will add the label to custom resources. The operator deleteOrUpdate handler should not apply labels to custom resources. It should only update the status subresource.

If we do not use a webhook but still want to use the operator to enforce these labels by updating metadata.labels, we can (vs we shouldn't as expressed above) . Actually updating the resource (as opposed to the status subresource) would trigger a new run of the deleteOrUpdate loop. As long as we handle this "double process" edge case then we can handle this in the operator without a webhook.

I'll work on making a PoC of handling the double processing so we can see what that would look like in practice. Designing the webhook is easy as well, but we would have to decide where to host the webhook images. A benefit of webhooks is that they are how we update resources between versions and are on our wishlist.

[wtrocki]

I thought that metadata.labels did not trigger resource updates (only spec will). That is why we could not use label to refresh resource in the Console UI and keep adding some generic field to spec. However if that is the case this really triggers some question if operator should be applying labels.

If there is large complexity in adding this label we can practically:

• Add label to examples (as other labels right now)
• Add label to CLI
• Add label to Console UI (already done)

[secondsun]

You're right. It doesn't update the generation which doesn't trigger the update. It also means if people remove the label then we can't update it to add it back either if we go via the operator route