https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
l
If you are ok doing outside the Pulumi project (bash or whatever) then you could use 
pulumi up --diff
and grep for the changed field. Undoubtedly there's an equivalent for automation-api code which would also work...
f
I was hoping for a solution where everything would be self-contained within the pulumi app itself. I’m using TypeScript and I have a SendGrid SMTP client library I’d like to use to send the email.
The outputs are just Promises, so we can detect when they have completed, however I’d like to discriminate when a change actually occurred… 🤔
l
Afaik there is no way to get the changed resources using the core Pulumi API. The automation-api API doesn't support 
diff
yet, but you could still get the fact that the password had changed from the 
UpResult.stdout
property.
The examples don't show an exact solution, but hopefully they'll inspire something: https://github.com/pulumi/automation-api-examples/tree/main/nodejs
f
The only doc I’ve found about 
UpResult.stdout
is this and it’s not much verbose! 😉 And what is the Automation API exactly? Is it an API for running pulumi stacks? It appears to me as something external to a stack and I’m hoping to stay within the stack boundary. We already have everything set up for running the stack externally, based on Git that triggers a CI/CD pipeline and runs the stacks.
l
Yes, the automation-api is a wrapper around Pulumi projects. It allows you to avoid calling 
pulumi
from the command line: you just run your golang or nodejs program, and Pulumi is invoked from within it.
Since there is (afaik) no way to get info on what changed from core Pulumi, you have to do it from outside the stack boundary. The automation-api is compatible with pipelines: you just change your existing 
pulumi up --yes
to 
yourStackApp
or whatever, and everything else remains the same.
f
makes sense… but I would hope to avoid that if possible… 😕
l
Except inside your automation-api program, you have a bit that is "outside the stack boundary", allowing you to effectively grep your console output.
f
yeah, understood, but then it would require `grep`ing or some amount of text parsing to detect changes… 🤔 that’s quite far removed from the neat object-oriented resource model…
l
I guess your use case hasn't occurred to them yet. You could raise a feature request in github?
f
possibly!
might be quite involved, but I’m maybe thinking developing a custom resource for that? it would store its own state, be able to compare input with state and call an arbitrary side-effect func when a change is detected… 🤔
l
Maybe. I was wondering if storing old values and comparing could be made to work, but since you're talking about passwords, I think that should be avoided...
f
they will only be temporary passwords, and we’re considering living with the fact that they end up into state
is creating custom pulumi resources with arbitrary inputs/outputs much involved? I’m not finding any doc on the subject…
l
It's no less secure than emailing them 🙂
No it's trivial. Look up 
ComponentResource
.
I'm confident that the create-iam-user-and-get-their-password-to-them problem has already been solved. I wonder if there's a Pulumi example for it...
f
already asked our account executive that question, will see what he answers! 😉
Extending 
ComponentResource
(or `CustomResource`/`Resource`) really looks promising, but I can’t find any simple examples of how to do that… I’m trying to figure it out from the source code, but that’s not trivial… 🤔
l
I have loads of examples. Let me find a sufficiently-generic one...\
f
I’m not even sure I need an underlying provider (or do I?)
l
That's handled in the normal way, via 
opts
.
An EC2 instance with an encrypted root volume. The instance, key and keypair appear as children of the component resource.
EncryptedInstance_ts.ts
Provider can be passed in via opts, 
const machine1 = new EncryptedInstance("machine1", { /* your args */ }, { provider: yourProvider });
The 
instnaceArgs
method is not needed. I just did it because there's so many args for an EC2 instance....
f
But the way I see it, 
ComponentResource
is really intended to group child resources into an higher level resource. What I was thinking of creating is really a standalone resource with no underlying provider and no child resources. It would just have one input that would take in the password, it would compare that to current state (not sure how pulumi allows to save/load state though) and it would send an email if input password is different from state. So you see, it’s not really grouping other resources underneath it. Maybe 
CustomeResource
or just 
Resource
would be a better fit… I would just connect my user’s password Output into that resource’s Input and that’s it… 🤔
However, I really like the idea of the 
ComponentResource
for other things. I could use it to group all my user-related resources into a higher-order user component resource. It would be cleaner and easier to visualize. But I don’t think that’s what I need for sending emails (which is just some side-effect, not a child resource).
However, by looking into the source code, it looks like no matter what I will have to implement a custom provider, to handle the CRUD operations. I would only implement the Create and Update operations, which would both send the email.
l
You could use a ComponentResource that wraps the UserProfile and stores the encrypted old password and encrypted new password.
If they're not stored with a key, and there's no way to map them to a key, it should be reasonably safe.
f
Indeed, I see what you mean. But then, how would I save/load my own state for the password?
l
I would grab the encrypted password out of the nested UserProfile object.. does it make that available? Onesec...
Though creating your own provider for the UserLoginProfile would work just as well... I presume it can delegate to the real AWS provider... and it's got hooks for detecting change. That might be better, I've just never done it...
f
I need to call it a day for now, but thanks a lot @little-cartoon-10569, you’ve been super helpful! 🙏 I’ll continue looking into it tomorrow. See you around! 🙂
l
👋
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