muvaffak

The usual update process is to change `spec.image` of the `Provider` object but it seems like Helm chart creates a new `Provider` object when a different version is chosen since...

@cihangirbesiktas opened https://github.com/crossplane/crossplane/issues/2609 regarding the Helm upgrade process.

There are a few aspects I believe worth mentioning: * One of the main reasons of the need for `dry-run` is to make sure no managed resource is accidentally deleted,...

If I'd like to patch `spec.forProvider.bArr[0].targetSelector.matchLabels[key2]` and other properties of `spec.forProvider.bArr[0]` get affected by this for some reason, I'd say this is a bug regardless of the underlying machinery. So...

@negz Oh yeah, my comment wasn't really directed towards what approach we'd like to take. Just wanted to change it to be considered as a bug, which I think would...

I just gave it a shot. Added an applicator to crossplane-runtime in https://github.com/crossplane/crossplane-runtime/pull/358 that uses server-side apply as described [here](https://github.com/kubernetes-sigs/controller-runtime/issues/347). First, I wanted to reproduce the behavior with what @ulucinar...

I ran another experiment today with the OpenAPI markers. In SSA, you can designate a field to be the identifier of the array item and I did that by adding...

I ran another experiment implementing my alternative client-side solution, i.e. unblocking the use of `UPDATE` by generating `fieldpath.SetValue` statements from the raw base template so that the whole loop consists...

I've just updated the client-side experiment https://github.com/crossplane/crossplane/pull/3347 . Now, it's just a new `ApplyOption` that patches current object with every field of the desired state. It's working as expected with...

> I think we should be biasing for moving toward SSA rather than extending (further diverging) our client-side patching logic. Agreed but I think there should be a ceiling to...