Earlier quoted context omitted.
Huh so you access your infra through terraform?
This conversation is embarrassing for both of you.
its super embarrassing if you thing TF is the source of truth when the cloud provider clearly is
Terraform should have remained stateless
321–329 of 329 posts
Re: Terraform should have remained stateless
#322Earlier quoted context omitted.
I can’t imagine you would ever hit a rate limit, how often are you deploying large sums of infrastructure? For me it’s maybe a couple times a day and the surface area is small
AWS API Rate limits are very surprising. I've hit them on new accounts when trying to deploy terraform based code, and that's without having to literally scan the entire account. If I have 3k machines running in an autoscaling group I think it would be ridiculous to have to hit each one of those with API calls to try and infer which were or weren't part of my state. Building a simple high availability VPC is about 72…
Huh I've never hit rate limiting on GET with AWS, could just be my luck. This also might not be the answer for every problem, but could be nice for some
Re: Terraform should have remained stateless
#323Earlier quoted context omitted.
Pulumi also has a newer iteration that uses provider APIs directly. A pain point has been that terraform provides tend to lag significantly with platform APIs, or just miss some functionality entirely.
The providers are maintained by dedicated teams of Amazon, Microsoft, Alphabet, Hashicorp themselves, other big corps. Pulumi abstractions are updated by a single corpo team. Ill be EXTREMELY surprised if they wont laaaggg alot more behind when they start supporting more and more platforms. Its simply a matter of amount of ppl working on the tool.
Agreed in principle. In this instance they have basically rigged up a machine to poll and parse the GCP API Discovery service into a native provider. https://developers.google.com/discovery/v1/using
It’s promise is sustainably same-day parity with platform APIs. It is generated code, so it may not be semantically pleasing, but it should just work. I haven’t spent much time with it to form a nuanced opinion but I do think it’s a novel and reasonable approach.
https://www.pulumi.com/blog/pulumiup-google-native-provider/
Re: Terraform should have remained stateless
#324Re: Terraform should have remained stateless
#325Re: Terraform should have remained stateless
#326Earlier quoted context omitted.
AWS API Rate limits are very surprising. I've hit them on new accounts when trying to deploy terraform based code, and that's without having to literally scan the entire account. If I have 3k machines running in an autoscaling group I think it would be ridiculous to have to hit each one of those with API calls to try and infer which were or weren't part of my state. Building a simple high availability VPC is about 72…
Huh I've never hit rate limiting on GET with AWS, could just be my luck. This also might not be the answer for every problem, but could be nice for some
“I have never” doesn’t equal “it doesn’t happen”.
Re: Terraform should have remained stateless
#327Re: Terraform should have remained stateless
#328Earlier quoted context omitted.
It’s small, under 50 servers running OpenBSD and Linux under a wide variety of configurations (including gpu), 6 databases, and Redis. Though the system is easily extensible to other clouds and resource types, it only needs to work on GCP right now. Been running it in prod for the past 3 or 4 years—no outages, no downtime, no surprises. Doubled infra over the holidays then scaled everything back with no issue. The st…
This is the reason we didn't get Terraform. In a windows shop the state is never the same because most people will fix it via the UI and then the state file becomes useless
sounds like a totally reasonable decision
Re: Terraform should have remained stateless
#329State or Idempotency. Pick one. If you want stateless, then you can use Ansible and use their providers. Enjoy spawning new instances everytime you change your infrastructure, rather than having existing ones change.
You can also use Ansible with Jinja2 templating to generate your Cloudformation templates. Describe loops and other properties in Ansible and have it build out a complex Cloudformation template for it to deploy. Use an Ansible variable for your stack name so you update/delete an existing stack and your good to go. Could even break it down to environments so dev = smaller instances vs stage/prod etc.
That just shifts where the state is being stored. Once you use cloudformation, it's being stored on S3, which you can do with terraform anyway.