Steven Hawkins

> Is the idea to change all calls to io.fabric8.kubernetes.client.dsl.internal.PodOperationContext#withContainerId(String containerId) to use the first containerId from an internal collection of container IDs? The logic would roughly be - if...

> What are the possible user cases to be handled? Just the first one is what is currently problematic wrt user expectations. kubectl defaults to the first container, the fabric8...

Related to #3420 #2060 #3566 The simplest change that would get much closer to an apply would be instead of a replace doing a json patch.

@manusa @rohanKanojia I'm not sure what all of the rationale behind not supporting apply were in the past. From what I can guess the logic to do this looks approximately...

Linking to #3334 as well for server side apply support. More than likely we don't even have to add the last-applied-configuration and can just rely on issuing patches as application/apply-patch+yaml

See https://github.com/fabric8io/kubernetes-client/issues/3334#issuecomment-1062076433 for 6.0 server side apply support. Additional apply support will be considered for 6.x.

@sunix @rohanKanojia it would probably be good to still have an issue for a higher-level apply or serverSideApply method. That will be easier for users to find.

This change should be applied to DefaultServiceCatalogClient as well.

> I think the best would be to implement metrics with micromete, seer: #64 Yes, that is the approach we are taking with the quarkus + micrometer integration. > What...

We talked about sharding approaches on https://github.com/fabric8io/kubernetes-client/issues/3587#issuecomment-1014652601 and the related pr. Instead of a webhook we were talking about a "coordinating" operator being responsible for assigning indexes to the resources....