4 ms·

> You're not even _using_ a database to store your state, you're just using SQL to produce some graph of things you need to reconcile. Well, that's one way of

> You're not even _using_ a database to store your state, you're just using SQL to produce some graph of things you need to reconcile. Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state. That also solves: > You would create all these resources, then modify them, then delete them, then create some new resources as a linear history of operations. Not good, very brittle. When you have an actual database backing your SQL queries, the migrations would all run in this DB, produce a final state of the DB, then this final state would get applied to bring up your system in one shot. > So you'd need to add a unique identifier to every `INSERT` statement: Sure, and that's fairly easy to derive, because we already have a unique identifier, the bucket name: INSERT INTO aws_kms_key (node_id) VALUES (concat('aws_kms_key', bucket_name)) RETURNING arn INTO kms_arn;

orf 5y ago
> Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state It doesn’t matter how the state is stored, you still need to reconcile it. So yeah you can write your target state into a database if you wish, but you need something else to compare that with the state of the actual world and progress that towards the state you requested. > When you have an actual database backing your SQL queries, the migrations would all run in this DB, produce a final state of the DB, then this final state would get applied to bring up your system in one shot. Yes, what you are describing is how Terraform works. Without SQL. Except it’s never “one shot” because it’s a DAG of requirements where each resource creation can fail. > Sure, and that's fairly easy to derive, because we already have a unique identifier, the bucket name In this specific case, sure. But for a KMS key or in the general case, no you wouldn’t. You’d also be hard-coding provider specific information into your system - “a bucket ARN can be derived from the name attribute”. This is not always the case - consider any REST api that accepts a POST request to create something, but returns only an incrementing integer primary key to uniquely identify it.

orf 5y ago

> Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state It doesn’t matter how the state is stored, you still need to reconcile it. So yeah you can write your target state into a database if you wish, but you need something else to compare that with the state of the actual world and progress that towards the state you requested. > When you have an actual database backing your SQL queries, the migrations would all run in this DB, produce a final state of the DB, then this final state would get applied to bring up your system in one shot. Yes, what you are describing is how Terraform works. Without SQL. Except it’s never “one shot” because it’s a DAG of requirements where each resource creation can fail. > Sure, and that's fairly easy to derive, because we already have a unique identifier, the bucket name In this specific case, sure. But for a KMS key or in the general case, no you wouldn’t. You’d also be hard-coding provider specific information into your system - “a bucket ARN can be derived from the name attribute”. This is not always the case - consider any REST api that accepts a POST request to create something, but returns only an incrementing integer primary key to uniquely identify it.