DynamoDB keys vs CloudFormation examples

[Redundancy]

I'm trying to reconcile this:

class PrimaryKey(AWSProperty):
    props = {
        'HashKeyElement': (Element, True),
        'RangeKeyElement': (Element, False),
    }

class Table(AWSObject):
    type = "AWS::DynamoDB::Table"

    props = {
        'KeySchema': (PrimaryKey, True),
        'ProvisionedThroughput': (ProvisionedThroughput, True),
        'TableName': (basestring, False),
    }

with:

"KeySchema" : [
          {
            "AttributeName" : "Album",
            "KeyType" : "HASH"
          },
          {
            "AttributeName" : "Artist",
            "KeyType" : "RANGE"
          }
        ],

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-dynamodb-keyschema.html

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html#cfn-dynamodb-table-keyschema

This doesn't seem to match up - is it wrong, out of date or am I misunderstanding something?

[markpeek]

Well...now that you mention it I'm trying to understand what is supposed to be correct. Here are two conflicting templates DynamoDB_Table.template and DynamoDBSI.template. I agree the documentation currently shows using AttributeName/KeyType but I need to rationalize why there are these two forms. I'm wondering if this changed at some point in time.

[Redundancy]

I made a quick and dirty modification locally to match the form in the examples I posted, and it seems to work on a test deployment that I did (fwiw). I couldn't really work out, based on the "dates" of the API how it was supposed to match up.

Perhaps this should be a different issue, or feature request, but I've noticed that constructing Arns for IAM profiles is a pain in the ass in CloudFormation due to sketchy coverage of GetAtt( , "Arn"). For example, I think that the correct way of constructing a dynamoDB Table Arn is:

        return Join("", [
            "arn:aws:dynamodb:",
            Ref("AWS::Region"),
            ":",
            Ref("AWS::AccountId"),
            ":table/",
            Ref(logical_table_name)
        ])

This is potentially something that troposphere could help make a lot easier.

[markpeek]

I believe what you want to do is install the AWACS library which is intended for use with troposphere to create IAM policies and can be used for ARN's as well.

[neg3ntropy]

It seems to me that the current implementation is broken, at least for me.

[markpeek]

Can you provide more details on what you are doing and what you believe is broken?

[Redundancy]

I'll try to post a CloudFormation definition of a dynamoDB table that I've successfully deployed on Monday - it seems to me that the other template is wrong, and the docs are correct.

[neg3ntropy]

Contrary to my previous comment, the current implementation does work, even if it does not match the cloudformation docs.

However we went with (partially) updating troposphere to bring it in par with the current cloudformation syntax. It seems to me that it is time to revise the dynamo module extensively.