https://pulumi.com
Join Slack
I have trouble installing default example configuration of opensearch: <https://github.com/opensearc...
# kubernetes
g
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:
Copy code
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..?
Copy code
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
i've removed the chart and did pulumi refresh and them pulumi up it went well. when i've did pulumi up again got the same error.
m
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.
g
probably the operator
the other way i could do this probably by using crd directly instead of chart, but that crd probably would be modified too
m
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
g
how to know which field
that's a lot of things to grasp in here 😄
💯 1
m
It's in the error message: "Apply failed with 1 conflict: conflict with "Go-http-client" using opensearch.opster.io/v1: .spec.nodePools"
And you can see who's in charge of which field by looking at 
metadata.managedFields
, see this example in the k8s docs
g
so to add something like this at the end of the chart() ?
Copy code
opts=ResourceOptions(ignore_changes=["prop"]))
just not sure what to ignore.
m
Going from what's in the error message, you want to ignore "spec.nodePools"
g
grateful for saving my sleep
m
Alternatively, you can force an override and have Pulumi "reset" the field and take ownership again (see the docs Iinked in the error message).
In either case you need to make sure that the option you choose makes sense in your context.
g
i'd probably respect the wish of operator lol
oh wait but that means that i won't be able to modify specs.nodePools
✅ 1
that's not good
m
Yes, in which case you probably want to add a patchForce annotation
g
by reading the example it's so highly unclear
m
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
g
probably this part is unclear
Copy code
data={
                                           "foo": "bar",
                                       },
i have no idea what exactly to patch
m
Yes, that's confusing. The only thing you need is
Copy code
annotations={
                                               "<http://pulumi.com/patchForce|pulumi.com/patchForce>": "true",
                                           },
You cannot do this selectively, it's either "force everything into my desired state" or the default behavior
g
Could you please tell me what instead of "example" should be in place 😕 ?
m
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
Could you please tell me what instead of "example" should be in place 😕 ?
The name of your resource. You have to modify your current resource definition. Like this:
👀 1
Old:
Copy code
resource = k8s.some.Resource("my-resource", metadata={"name": "my-resource-1"})
New:
Copy code
resource = k8s.some.Resource("my-resource", metadata={"name": "my-resource-1", "annotations": {"<http://pulumi.com/patchForce|pulumi.com/patchForce>": "true"}})
It's just an annotation in the metadata that acts as a tag/marker for Pulumi
g
I see. putting into the chart resource
👍 1
Copy code
opensearch_cluster_chart = k8s.helm.v3.Chart(
        "opensearch-cluster",
        metadata={
            "name": "opensearch-cluster",
            "annotations": {"pulumi.com/patchForce": "true"}
        },
        k8s.helm.v3.ChartOpts(
            chart="opensearch-cluster",
            version="2.6.1",
            fetch_opts=k8s.helm.v3.FetchOpts(
                repo="<https://opensearch-project.github.io/opensearch-k8s-operator/>"
            ),
            namespace=namespace,
            values=values
        ),
        opts=pulumi.ResourceOptions(provider=k8s_provider)
    )
makes sense?
also not sure if this additional param required like stated in docs:
Copy code
provider = kubernetes.Provider("k8s", enable_server_side_apply=True)
according to chat gpt it should go to here:
Copy code
opts=pulumi.ResourceOptions(
            provider=k8s_provider,
            depends_on=[opensearch_ns],
            custom_metadata={"annotations": {"<http://pulumi.com/patchForce|pulumi.com/patchForce>": "true"}}
        )
@modern-zebra-45309 can't find that chart() resource would have metadata field at all
it didnt help 😞
Copy code
kubernetes:<http://opensearch.opster.io/v1:OpenSearchCluster|opensearch.opster.io/v1:OpenSearchCluster> (opensearch-cluster:opensearch-cluster/opensearch-cluster):
    error: resource "urn:pulumi:dev::infra-eks-utils::kubernetes:<http://helm.sh/v4:Chart$kubernetes:opensearch.opster.io/v1:OpenSearchCluster::opensearch-cluster:opensearch-cluster/opensearch-cluster|helm.sh/v4:Chart$kubernetes:opensearch.opster.io/v1:OpenSearchCluster::opensearch-cluster:opensearch-cluster/opensearch-cluster>" was not successfully created by the Kubernetes API server: 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-725b70ee" had an apply conflict: Apply failed with 1 conflict: conflict with "Go-http-client" using <http://opensearch.opster.io/v1|opensearch.opster.io/v1>: .spec.nodePools
m
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.
Which of these options make sense for you is hard to say, but you should have multiple options to pick from.
🙌 1
g
Probably will have to go toward deploying crd instead of chart and then put push patch on it
g
@modern-zebra-45309 sorry for silly question but does ignoreChange overwrites the resource, or it for pulumi to ignore changes which happenned in resource?
m
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/
g
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.
will transformation for chart/release would work?
m
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.
g
Chart is an opensearch cluster chart which created crd
This is not operator chart it’s the one which provided crd for operator
Operator chart seems to be fine
95 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by