Peter Bengtson

Well, we don't want hard, fully specified names in _any_ situation, as this makes it impossible to replace the resource.

"Be aware that not all resources use the stackname in the generated name (eg RDS)" ... which then immediately makes that particular solution not viable. I'm sure we're not alone...

Am I understanding you correctly that the Aspect solution and the `Stack.allocateLogicalId` solution both lead to fully specified resource names, i.e. "hard" names?

I would add, Richard, that the proposed solution would apply the prefix to all resources, not just some, obviating the need for selective documentation. It would be completely binary and...

Yes, I of course agree that tags would be infinitely better. No, of course we don’t want to specify physical names, for precisely the reasons you mention. However, as i’ve...

Thanks for the example code, Elad! :) On Fri, 13 Sep 2019 at 15:10, Peter Bengtson wrote: > Yes, I of course agree that tags would be infinitely better. No,...

Thank you, Elad. :) fre 13 sep. 2019 kl. 16:14 skrev Elad Ben-Israel : > okay thanks for the clarification. I’ll think about this some more and see > if...

Just get rid of it completely. The present solution is over-engineered.

It very much seems that you'll have to use a custom resource for adding/removing a client certificate. This of course always works, but it's wordy and kludgy and a royal...

Removing those lines fixes the syntax, but running the template yields `ResourceLogicalId:Subscriber, ResourceType:Custom::Subscriber, ResourceStatusReason:Received response status [FAILED] from custom resource. Message returned: See the details in CloudWatch Log Stream: 2022/06/17/[$LATEST]128be64879a64b03a1bb02f4e84f679f...