I have trouble installing default example configuration of opensearch: https://github.com/opensearch-project/opensearch-k8s-operator/blob/main/opensearch-operator/examples/2.x/opensearch-cluster.yaml Operator installed fine. Also I'm using chart for CRD and default config should be fine: http://dpaste.com//8HCW2U8UL So when I'm deploying opensearch cluster chart I've got this error:

Diagnostics:
  pulumi:pulumi:Stack (infra-eks-utils-dev):
    error: preview failed

  kubernetes:opensearch.opster.io/v1:OpenSearchCluster (opensearch-cluster/opensearch-cluster):
    error: Preview failed: 1 error occurred:
    	* the Kubernetes API server reported that "opensearch-cluster/opensearch-cluster" failed to fully initialize or become live: Server-Side Apply field conflict detected. See <https://www.pulumi.com/registry/packages/kubernetes/how-to-guides/managing-resources-with-server-side-apply/#handle-field-conflicts-on-existing-resources> for troubleshooting help.
    The resource managed by field manager "pulumi-kubernetes-fa75979c" had an apply conflict: Apply failed with 1 conflict: conflict with "Go-http-client" using opensearch.opster.io/v1: .spec.nodePools

And what's interesting pods are running fine..?

holms@Romans-MBP-2 ~/D/p/i/i/eks_utils (main)> kubectl get pods -n=opensearch-cluster
NAME                                             READY   STATUS      RESTARTS   AGE
opensearch-cluster-dashboards-68bfb4bd48-xzxjs   1/1     Running     0          43m
opensearch-cluster-masters-0                     1/1     Running     0          43m
opensearch-cluster-masters-1                     1/1     Running     0          41m
opensearch-cluster-masters-2                     1/1     Running     0          39m
opensearch-cluster-securityconfig-update-j4cdd   0/1     Completed   0          43m

holms@Romans-MBP-2 ~/D/p/i/i/eks_utils (main)> kubectl get deployments -n=opensearch-cluster
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
opensearch-cluster-dashboards   1/1     1            1           45m

Source here: http://dpaste.com//DFR3MJABP and here http://dpaste.com//7RHPZHHX6

Did you follow the link in the error message? tl;dr Something other than Pulumi is modifying the resources and taking ownership of a particular field, leading to a conflict.

probably the operator

Yes, this will always happen, it's not a bug or a negative thing. There is a "Go-http-client" that's taking ownership of a particular field. Your best strategy is to have Pulumi ignore this particular field, see Handle Field Conflicts on Existing Resources

how to know which field

It's in the error message: "Apply failed with 1 conflict: conflict with "Go-http-client" using opensearch.opster.io/v1: .spec.nodePools"

so to add something like this at the end of the chart() ?

opts=ResourceOptions(ignore_changes=["prop"]))

just not sure what to ignore.

Going from what's in the error message, you want to ignore "spec.nodePools"

grateful for saving my sleep

Alternatively, you can force an override and have Pulumi "reset" the field and take ownership again (see the docs Iinked in the error message).

i'd probably respect the wish of operator lol

Yes, in which case you probably want to add a patchForce annotation

by reading the example it's so highly unclear

I recommend going through the Server-Side Apply doc once from top to bottom, it does a good job to explain the idea and discusses conflict resolution, ownership transfer etc

probably this part is unclear

data={
                                           "foo": "bar",
                                       },

Yes, that's confusing. The only thing you need is

annotations={
                                               "<http://pulumi.com/patchForce|pulumi.com/patchForce>": "true",
                                           },

Could you please tell me what instead of "example" should be in place 😕 ?

This matches https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts. The annotation tells the Pulumi k8s provider to apply the change like

kubectl apply --force-conflicts=true

I see. putting into the chart resource

The annotation has to go on the Kubernetes resource in question. Did you verify that this is the case for the resource that has the conflict? Sometimes Helm charts provide a way to add custom annotations. If not, you can either define transformations on the Pulumi Chart resource (this is not the same as the transformation you specified in the resource options), or find and patch them after they are created (in your case, CustomResourcePatch is probably what you'd need), and sometimes you'll have to modify the Helm chart yourself.

Probably will have to go toward deploying crd instead of chart and then put push patch on it

@modern-zebra-45309 sorry for silly question but does ignoreChange overwrites the resource, or it for pulumi to ignore changes which happenned in resource?

ingoreChanges is a Pulumi feature (not a Kubernetes feature):

Pulumi ignores a property by using the old value from the state instead of the value provided by the Pulumi program when determining whether an update or replace is needed. Ignored properties will still be used from the program when there is no previous value in the state, most importantly when creating the resource.

see https://www.pulumi.com/docs/concepts/options/ignorechanges/

Oh ok so this one definitely fits well. The only problem is finding the resource URN..? Or it's better to have crd manifest applied straight away without chart and set to ignore changes there.

This is really difficult to say without understanding your use case in depth. From what you've written here, it also doesn't look like that the CRDs are affected, but a specific custom resource that is created by the Helm chart.

Chart is an opensearch cluster chart which created crd