undefined | Better HN

0 pointsjen202y ago0 comments

That… is state, just stored elsewhere. It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.

0 comments

cyberax2y ago

> That… is state, just stored elsewhere.

The state is stored in the resources themselves, to be precise.

> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.

You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.

API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.

State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.

jen20OP2y ago

There may be no services at large that don’t support tagging (certainly was historically not the case though), but there a hundreds of resources that don’t.

Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).

Finally, how would you manage tags as an actual resource themselves in this model?

cyberax2y ago

For resources that don't support tagging or user-defined naming, you'll need state.

> Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).

You can fix your IAM. Cost allocation tags are treated specially.

> Finally, how would you manage tags as an actual resource themselves in this model?

Why would you do that?

j / k navigate · click thread line to collapse

0 comments

cyberax2y ago

> That… is state, just stored elsewhere.

The state is stored in the resources themselves, to be precise.

> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.

API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.

State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.

jen20OP2y ago

There may be no services at large that don’t support tagging (certainly was historically not the case though), but there a hundreds of resources that don’t.

Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).

Finally, how would you manage tags as an actual resource themselves in this model?

cyberax2y ago

For resources that don't support tagging or user-defined naming, you'll need state.

> Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).

You can fix your IAM. Cost allocation tags are treated specially.

> Finally, how would you manage tags as an actual resource themselves in this model?

Why would you do that?

j / k navigate · click thread line to collapse