dynamic d_b_instance is ambigous

[autarchprinceps]

sparkle_formation-3.0.32/lib/sparkle_formation/resources.rb:169:in registry_key': Ambiguous dynamic name returned multiple matches!:d_b_instance` -> AWS::Neptune::DBInstance, AWS::RDS::DBInstance (ArgumentError)

Since the introduction of Neptune, dynamic!(:d_b_instance is no longer a valid option to create an RDS database.

[jimcroft]

This type of problem has cropped up before when OpsWorks support hit CF. Prior to OpsWorks using an unqualified instance for AWS::EC2::Instance was fine. Once AWS::OpsWorks::Instance became a thing the ambiguity error cropped up requiring us to switch that to ec2_instance instead.

I think using rds_db_instance (or similar) will work.

[autarchprinceps]

That would then rename the resource and force me to check every reference and attr. Not to mention create problems for updating stacks, especially with RDS

[jimcroft]

That's very true!

The 'Builtin Lookup Behavior' in docs call out the EC2 vs. OpsWorks issue from the past. I guess now Neptune's out a similar defaulting of :db_instance to AWS::RDS::DBInstance needs to be done.

Had a quick look in the source and can't see where that happens (assuming my thinking's right at all!) :)

One temporary solution might be to do something like https://github.com/sparkleformation/sparkle_formation/issues/200#issuecomment-285951234 and stub out your own :db_instance dynamic like:

SparkleFormation.dynamic(:db_instance) do |name|
  resources.set!("#{name}_db_instance".to_sym) do
    type 'AWS::RDS::DBInstance"
  end
end

Though no idea if that works or will just add another resource to the ambiguities!

[autarchprinceps]

I assentially did a similar thing, by simply replacing the last few included dynamics with resources. I'm not sure I get the purpose of them anyway. It's not like they translate parameters between the respective AWS or Azure use cases. I did not know that they do a dynamic lookup however.

[chrisroberts]

Hi! Using the resource namespace is generally a good idea especially for cases like this. There are not a lot of resource names that are shared between namespaces, but there are some and this sort of behavior can make it annoying when new ones are introduced. Depending on the usage size, renaming the dynamics might be a bit cumbersome (due to the tracking down of reference usage and the like) so you have a couple options. First, you can add the namespace and then force the correct suffix where you define the resource via the dynamic:

dynamic!(:rds_d_b_instance, :fubar, :resource_name_suffix => :d_b_instance)

Or, if you have multiple usages of dynamic!(:d_b_instance,...) around and want to just make that always mean "RDS::DBInstance", you can create a local dynamic which will always be the matcher. It would look like this:

SparkleFormation.dynamic(:d_b_instance) do |name|
  dynamic!(:rds_d_b_instance, name, :resource_name_suffix => :d_b_instance)
end

Having the local dynamic defined would automatically fix all currently defined RDS::DBInstance resources.

I'm going to close this but if you are still having any problems, or this doesn't fully resolve your issue, just reply and I'll reopen this.

Cheers!