https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
e
The protobuf specs are probably the best text on this: https://github.com/pulumi/pulumi/blob/master/sdk/proto/provider.proto We've got plans to see about rebuilding the go interfaces (and other languages) from something like protobuf automatically so all the code documentation would be filled in and kept in sync.
🙌 1
b
Thanks. So would param 
m map[string]interface{}
contain these properties of this struct when read is triggered: https://github.com/pulumi/pulumi/blob/master/sdk/proto/provider.proto#L258
Is there any publicly available example of Read method in custom provider? I’m trying to figure out how to combine Read on new and existing resources for importing.
e
I mean most of the providers implement Read but they're complex and not the easiest thing to read to learn from. And yes 
m
will the current set of inputs that the engine currently knows about, so it's only filled in for refresh, not for import (because obv on import it's brand new and the engine doesn't know anything)
b
Hmm, so in case of refresh, it fills the inputs + existing properties in this map?
e
No just the inputs
The expectation is that Read will be able to get the existing properties, because well that's what its for,
b
Gotcha. Hmm. This may need some rethinking.
e
A trick that comes up with this sometimes is people encoding information into the ID of the resource. Your provider can return whatever string it wants for ID and that same string will be passed back for Refresh
b
So, I have a resource that takes an input field and generates random PGP keys (2 output properties). But I need to migrate some existing keys to Pulumi stack.
As you mentioned, I wanted to encode existing pgp data into ID so Read would work with importing
But I’m not sure how to also set up Read to access data on refresh, since it would not have data in ID, but the keys still exist somewhere in state.
I’m probably just being dumb and missing something obvious.
e
No it's not dumb, its a tricky use case.
We've had a few things come up where people want something stateful but don't really have anywhere to store that state and want to just use the pulumi state. Currently we don't really have a good way to do that, no defined interfaces at least. You could just manually edit the state file JSON to add your keys, if you've just got a couple of these as a one off that would be my recomendation. If you think this is going to be a recurring scenario it'd be worth raising an issue on our github discussing this, we can then track that and see about adding a feature to have some sort of first class state access.
👍 1
b
Hmm, that might have some merit. Maybe first generating a resource and then updating generated state JSON manually with correct values? The import should be a one time operation anyway for my migration.
But that probably wouldn’t work with properties marked as secret right? Any way I could manually encrypt them?
e
Any way I could manually encrypt them?
Again nothing really supported, but just set it as a secret config value with 
pulumi config set --secret
then copy the encrypted text out of that
then just delete the config value once done. Again I think there's merit here to giving people first class support to state "somehow" and that would support secrets
b
Should work yes. Thanks for all your answers, this was super helpful.
2 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