This message was deleted.

Something in line with https://stackoverflow.com/a/55674129/1171619 ?

This looks very promising, is there a way to convert this to a managed resource? Maybe with

stack export

on the configuration using get() and then

stack import

on a configuration that defines the resource? Does that make sense?

How would the code definition of such resource appear?

Are you saying you want Pulumi to automatically generate code for an existing infrastructure and then import it as a stack?

I can write this code by hand, that's not the issue. I want to link the code I write to an existing resource, so that Pulumi can manage it without recreating on first run. Does that make sense?

I would guess that if you are careful with defining the code,

pulumi refresh

should get you where you want to be

I thought about doing this, but couldn't figure out what was needed to refresh to notice the existing resource. Do you know? I'm trying

export const database = new gcp.sql.DatabaseInstance('test-database-asd', {
  databaseVersion: 'POSTGRES_11',
  name: 'test-database-asd',
  settings: {
    diskAutoresize: false,
    diskSize: 10,
    diskType: 'PD_HDD',
    tier: 'db-f1-micro'
  }
});

AFAIK the

name

parameter defines the name used in the API, the same one that can be seen on GCP. I already have a Cloud SQL instance with that name, in the same zone, but it is not being discovered by

pulumi refresh

. Is there something else that needs to match up? I know there are some internal IDs being passed around, do I need to generate one of those?

Have you tried creating the same type of resource through Pulumi and seeing what names/ids are set on the cloud side?

I used

gcp.sql.DatabaseInstance.get('test-database-asd', 'test-database-asd');

, then ran

pulumi up

to fetch this data into the internal cache. Then replaced that code with a definition that matches the state of the resource in GCP. Then ran

pulumi refresh

and it went fine, unchanged. Then to test, I increased diskSize and ran

pulumi up

. It correctly diffed the state before & after, and is recommending a

replace

operation.

Yeah, I was wondering if the random characters were getting in the way

I feel like I'm really close, I ended up editing Pulumi's json file for my stack manually, but it still wants to recreate my database, even when there are no differences.

pulumi preview --diff
Previewing update (staging):
  pulumi:pulumi:Stack: (same)
    [urn=urn:pulumi:staging::estetio::pulumi:pulumi:Stack::estetio-staging]
    ++gcp:sql/databaseInstance:DatabaseInstance: (create-replacement)
        [id=test-database-asd]
        [urn=urn:pulumi:staging::estetio::gcp:sql/databaseInstance:DatabaseInstance::test-database-asd]
        databaseVersion: "POSTGRES_11"
        name           : "test-database-asd"
        settings       : {
            diskAutoresize : true
            diskSize       : 10
            diskType       : "PD_HDD"
            pricingPlan    : "PER_USE"
            replicationType: "SYNCHRONOUS"
            tier           : "db-f1-micro"
        }
    +-gcp:sql/databaseInstance:DatabaseInstance: (replace)
        [id=test-database-asd]
        [urn=urn:pulumi:staging::estetio::gcp:sql/databaseInstance:DatabaseInstance::test-database-asd]
        databaseVersion: "POSTGRES_11"
        name           : "test-database-asd"
        settings       : {
            diskAutoresize : true
            diskSize       : 10
            diskType       : "PD_HDD"
            pricingPlan    : "PER_USE"
            replicationType: "SYNCHRONOUS"
            tier           : "db-f1-micro"
        }
    <<gcp:sql/databaseInstance:DatabaseInstance: (discard-replaced)
        [id=test-database-asd]
        [urn=urn:pulumi:staging::estetio::gcp:sql/databaseInstance:DatabaseInstance::test-database-asd]
        databaseVersion: "POSTGRES_11"
        name           : "test-database-asd"
        settings       : {
            diskAutoresize : true
            diskSize       : 10
            diskType       : "PD_HDD"
            pricingPlan    : "PER_USE"
            replicationType: "SYNCHRONOUS"
            tier           : "db-f1-micro"
        }
Resources:
    +-1 to replace
    1 unchanged
Permalink: file:///home/kuba/.pulumi/stacks/staging.json

I'm not verse enough on Pulumi's internals to give a useful response, but it seems like its some kind of internal ID that's not matching up?

That would be my guess as well

I talked about how to do this previously at https://pulumi-community.slack.com/archives/C84L4E3N1/p1552146684342800?thread_ts=1552107055.338400&cid=C84L4E3N1.

I just figured it out as you sent these messages. I only have to remove the

"external": true

part of the JSON and it is reconciled properly

The import operation described in that issue?

I assume you meant

pulumi stack import

, right?

Oh, sorry. TBH, I'm not sure if the

stack import

command removes that.

I think my solution is the simplest and least laborious: I define my existing resources with

get(...)

functions, run

pulumi up

. Edit the stack json directly (or export -> modify -> import probably works too) to remove

"external":  true

, and that's it. No

refresh

is needed, although the first time you update this resource, the schema will change slightly, some keys move around etc. But it's not destructive. Thank you for the help, I will note down this solution in the import/adopt issue on GH, so others are aware.

But you still had to replace

get(...)

with a constructor at some point?

yes, forgot to mention it, it should happen directly before or after removing the "external" attribute