The issue of whether to use the term "resource name" or "resource ID" is not actually where this bug started. This bug was opened because OS::Heat::HARestarter consumes an identifier that is not always what the get_resource intrinsic function produces and is not accessible in another way. Maybe there are other resource types besides HARestarter that also have this problem, I am not sure. The simplest way to fix this would be to change such consuming resource types to consume a resource reference ID (i.e., what get_resource produces) instead of what they do today. Another way to fix it would be to introduce something a template author could write that produces what the consumer expects, for all types of referenced resource; I favor that less because it exposes an additional concept to template authors.
The issue of whether to use the term "resource name" or "resource ID" is not actually where this bug started. This bug was opened because OS::Heat: :HARestarter consumes an identifier that is not always what the get_resource intrinsic function produces and is not accessible in another way. Maybe there are other resource types besides HARestarter that also have this problem, I am not sure. The simplest way to fix this would be to change such consuming resource types to consume a resource reference ID (i.e., what get_resource produces) instead of what they do today. Another way to fix it would be to introduce something a template author could write that produces what the consumer expects, for all types of referenced resource; I favor that less because it exposes an additional concept to template authors.