Generate Cloud Formation resources definition

[brno32]

I'm using the Serverless Framework and think it would be useful if I could generate a cloud formation definition from a PynamoDB model.

Currently, I've defined this table in two places, once in my python code as the Pynamo model, and again in my serverless.yml file. This is because I want my table as part of my cloud formation template so that it's part of the stack for deletion, rollbacks, and outputs, but also because I might want to define extra characteristics for the table which may not be supported in Pynamo (using KMS for example).

Could this be supported? I'm thinking I'd want to do most of defining in Python, run a CLI command to spit out a CF definition, and then I could just paste that in my serverless.yml. People using SAM could do the same thing

[pdax-josf]

+1

[ikonst]

How could we produce a CF definition when PynamoDB has only a subset of what goes into a table's definition?

I think a useful addition would be a method validating (by calling DescribeTable) that the model is in congruence with the way its table is defined.

[brno32]

How could we produce a CF definition when PynamoDB has only a subset of what goes into a table's definition?

I suppose it wouldn't need the entire definition, but just the subset PynamoDB needs. I mainly want to avoid typing up the definition of my table twice, in two different languages is all. Typing it up once in python and again in CloudFormation is error prone, but I need to see my DynamoDB table as a cloudformation resource under a certain stack like the rest of the resources at play in my application

[ikonst]

I'm questioning the usefulness, since it's a one-time thing: what you're keeping in sync is the table and index names, the key names and their types. All of those are immutable once a table is created, so it's not something you have to constantly keep in sync.

(At work we usually define the resources first — we use Terraform — and only then define models in PynamoDB or whatever ORM/language a project uses.)

[pdax-josf]

The idea is to make the table and index declaration (models.py) as the single source of truth then update the config (serverless, terraform, or cloudformation) during deployment. But as I was typing this idea, I realized the possible danger of this approach.

Another idea is to automatically create the models.py file from the cloudformation template

[cmelgreen]

Generating a SAM or Cloudformation template that was compatible with the Chalice Lambda framework's --merge-template command would be a huge benefit for smaller PoCs and personal projects.

In general full IaC like Terraform is clearly more powerful but being able to quickly write both lambda functions and dynamodb tables based on simple python models would be a great combo.

And at least right now if you search for Lambda frameworks and Dynamodb orms for Python Chalice and Pynamodb are the top two results