Curious how folks out there are handling creating ...
# typescript
e
Curious how folks out there are handling creating an EC2 Instance and in the same stack, passing the Instance ID as a string for an SSM Parameter?
basically doing something like the following
Copy code
instance = new aws.ec2.instance(.......)

ssmParam = new aws.ssm.Parameter('ssmParam', { name: InstanceParam, value: instance.id }}
Always errors out
l
What's the error?
Not really a typescript issue though 🙂
a
One trick when I'm working with a new resource type is to create one by hand in a test account, with some of the settings I care about, and then import it into a stack to see the "Example" code. Helps me work thru docs that I don't find clear.
e
I chose the typescript because of promises
dont’ think this would be an issue with python
a
I agree with @little-cartoon-10569, need to see the error, and probably the value of
InstanceParam
l
I meant, this question could go in #general 🙂
e
basically passing this instance Id as a string always results in
"instanceId": "Calling [toJSON] on an [Output<T>] is not supported.\n\nTo get the value of an Output as a JSON value or JSON string consider either:\n    1: o.apply(v => v.toJSON())\n    2: o.apply(v => JSON.stringify(v))\n\nSee <https://pulumi.io/help/outputs> for more details.\nThis function may throw in a future version of @pulumi/pulumi.",
l
That implies that
aws.ssm.Parameter
isn't working the same as normal Pulumi resource constructors. Let me check the code.
e
here is the full snippet we’re using for the SSM Param:
Copy code
pulumi.all([params, sqlInstance.id]).apply(([paramsOut, sqlInstanceId]) => {
				if (element.ssmInstanceConfigParameterName) {
					new aws.ssm.Parameter(element.ssmInstanceConfigParameterName, {
						name: element.ssmInstanceConfigParameterName,
						type: 'String',
						overwrite: element.ssmInstanceConfigParameterOverwrite,
						value: JSON.stringify({
							params: paramsOut,
							instanceId: sqlInstanceId,
							outputLocation: {
								s3BucketName: 'mb-ssm-logs-ec2-sql-infra',
								s3KeyPrefix: 'ssm-logs'
							},
							documentName: associationName,
							region: process.env.NODE_CONFIG_REGION
						})
					});
				}
			});
l
Ah, that's radically different.
b
you're passing an
instance.id
to the
value
field and it doesn't take an output, you'll need an
apply
l
In this case, the type of value is string, so you need to be careful about interpolating. And as a double-gotcha, you are instantiating a resource inside an apply(), which is usually best avoided.
The value field is
pulumi.Input<string>
, @billowy-army-68599? At least in parameter.d.ts, it is.
e
yea, so the latest change I did was removing the pulumi.all
and just
Copy code
if (element.ssmInstanceConfigParameterName) {
					new aws.ssm.Parameter(element.ssmInstanceConfigParameterName, {
						name: element.ssmInstanceConfigParameterName,
						type: 'String',
						overwrite: element.ssmInstanceConfigParameterOverwrite,
						value: JSON.stringify({
							params: paramsOut,
							instanceId: sqlInstance.id,
							outputLocation: {
								s3BucketName: 'mb-ssm-logs-ec2-sql-infra',
								s3KeyPrefix: 'ssm-logs'
							},
							documentName: associationName,
							region: process.env.NODE_CONFIG_REGION
						})
					});
				}
l
It won't work without the .all, in this format. But it would be better to move the .all to be part of the value property, rather than wrapping the constructor.
Let me have a go at refactoring, onesec.
b
oh interesring, it was a string last time I used it. Ignore me
l
(Untested!)
e
lol, well I just ran it and it looks to work!
l
Awesome!
If you have any
apply()
code containing a resource constructor, refactor it like this. The dependencies work much better, and so does pulumi preview.
e
you are amazing! Next step is testing it now with a net new box, since my last try the instance created but ssm failed, so pulumi knew about the ID this time around, next run it shouldn’t and will be the true test
yes, absolutely
you rock
l
Aww shucks
g
The concept of
Input
and
Output
is possible the hardest in Pulumi to grasp completely but it does make sense and once you get it it is really nice way to handle the problem. It also enables resource wait functionality via dependency tracking which is just pure awesomeness