Hello everyone, hope you're well! I'd very much a...
# general
Hello everyone, hope you're well! I'd very much appreciate your help regarding out issue: When we're trying to create an account with transit gateways and peering we're having problems with peering attachments, as per the documentation, you have to later accept the peering request, thing is, once you create a
the returned output is only the ID of the
, when you create a peering, essentially two parameters are created, one in the source account + region, and another in the target account + region. When you run the
you need the ID of the
. I've tried pulling it with get_peering_attachment in the target account and filtering by the Transit Gateway (target and source IDs) and it can only accept a
result, anything other than one result will fail the execution. I've tried working around this with
to use describe_transit_gateway_attachment, but I'm having problems with consistency (the values returned from Output) are malformed and it says "<Object at 0x12341234>" instead of the value. Would really appreciate any leads on how to proceed, have a great day!
So for the
, what are you returning? Pulumi returns inputs as outputs, as well, so you can return
as an example. Perhaps you need to return one of the transit gateway IDs like that, instead?
Sorry for the massive delay, we had passover over here 🙂 It's not me who's returning, it's the Pulumi that returns that. When you use create a
it returns the ID of the request, but I need the ID of the
, the barrier here is that the approver might be on another account. When I tried to get it using the
, it wouldn't let me filter it using multiple search criteria, and when you receive anything other than one result it fails completely, even if nothing matched.
My problem isn't knowing the
it is knowing the
in the target account
Right, the accepter is the peer transit gateway (based on AWS's terminology), which would be one of your inputs for
as the
. That's an input, which you can also return as an output since Pulumi maps inputs to outputs, as well. Unless I'm misunderstanding what you're trying to do? When it comes to the boto3 workaround you mentioned, that object you're getting is because you're likely trying to use the output directly. Outputs behave a lot like promises because they aren't known until provisioning is complete. Depending on the language you're using, you call different methods to transform that object into something you can use. One of our engineers wrote a great blog post explaining how outputs work in Pulumi in case that helps explain it.
Again, that is not my problem. I am aware of that, the thing is that the
is unable to retrieve something that is not a single object.
Copy code
get_peering_attachment -> len(result) == 0 -> error: no matches found
get_peering_attachment -> len(result) > 1 -> error: multiple results found, add filters, narrow the search
get_peering_attachment -> len(result) == 1 -> success
Same with