https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
s
To which resource(s) does it happen? Do you know which fields may be different? It seems that the diff doesn’t show that, yet: https://pulumi-community.slack.com/archives/C84L4E3N1/p1574274572026200
In order to
successfully import a resource, its desired configuration (i.e. its
inputs) must not differ from its actual configuration (i.e. its state)
as calculated by the resource’s provider.
https://github.com/pulumi/pulumi/pull/2893#issue-293527337
That’s intended as a gate to not accidentally overwrite it with `pulumi up --yes`: https://github.com/pulumi/pulumi/pull/2893#issuecomment-509771727
h
I tested this with 
Service
and 
Deployment
Objects so far. I can see precisely which fields differ, pulumi offers a great view into this. It looks like this:
Copy code
warning: inputs to import do not match the existing resource; importing this resource will fail
    = kubernetes:core/v1:Service: (import)
        [id=microservice-example-ihrhjljj]
        [urn=urn:pulumi:dev::pulumi::kubernetes:core/v1:Service::microservice-example]
        [provider=urn:pulumi:dev::pulumi::pulumi:providers:kubernetes::default_1_3_1::04da6b54-80e4-46f7-96ec-b56ff0331ba9]
      ~ spec: {
          ~ selector: {
              ~ tier: "backend" => "frontend"
            }
        }
s
So, when you change the 
selector
to 
tier: backend
in your code, then the import should work, or?
h
Yes, it very much does work then.
3 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