Suddenly getting `subscription plan: lemming is not valid`

[floge07]

Terraform Version: 1.7.3 Cloudamqp Provider Version: 1.29.3

Reached the limit of free instances in my Cloudamqp Team. Which I wasn't aware it was a thing. The error message the provider gave me also didn't help:

Error: 1 error occurred:
│   * subscription plan: lemming is not valid

Unsure if this limit is mentioned anywhere on the normal web UI since I only ever created cloudamqp resources via terraform. So it probably would be good to mention it on the plans page.

Also, I don't think it is that great that this error is aborting the terraform plan step. Although I understand that the goal is probably that the apply shouldn't suddenly fail if the plan was successfully made.

[tbroden84]

Hi,

Yes, we have an upper limit on how many free plans we allow per team. Look like you hit this threshold. From the provider version v1.26.0 released in May 2023, we started to validate plan and region to our API backend. This is done every time during the planning step when a new cloudamqp_instance is created or when the plan has changed.

Please email support at cloudamqp.com with more information about your team/user and we can double check this.

[floge07]

Hi,

we for sure have currently hit that free instance limit. Now that we figured out that this is the cause our PM is going to get in contact, but that is a private discussion.

On my part, I kinda have to figure out now how to get our infrastructure pipeline working again. That for_each on the cloudamqp_instance is based on - let's call it - runtime data.

So I can't just so easily delete those "items" again. (This whole thing might be highlighting some weaknesses in our setup). Cleaning up others also doesn't seem to help. This error occurs as soon as we have 1 [create] with a free plan. This also prevents any other resource changes that are not even dependent on the cloudamqp_instances.

I think the experience when getting into this situation could be improved a bit. The error message itself and I don't think it should fully abort the plan and apply. Unsure how complex that would be, our situation tbf also seems like quite the edge case.

[dentarg]

Thanks for the feedback @floge07 – we're looking forward to hear from your PM

We agree that the experience in this situation could be better. The hard limit on free instances is there to prevent abuse, but we're very open to adjust it for legitime use-cases. We can do better to communicate this.

I don't have good suggestion for how to workaround this in your setup, besides creating another team, but I suspect that isn't ideal for you. To unblock you right now, the limit has been raised. Can you check if your pipeline works now?

[floge07]

@dentarg Yeah, that makes sense and is fair. And it's good to hear that this is not an unchangeable blocker.

I can confirm that our pipeline works again. Btw I'm quite positively surprised about the level I support I got here since this isn't even the official support channel. I was just going to report how the provider is behaving a bit annoyingly/confusing in that situation (especially if you didn't even know there is a limit).

I should also mention that we only got into this situation today because we were doing a huge load test. Glad we noticed this now instead of later. Well that's what testing is for ^^

So this was not the most urgent situation. I guess I wasn't that clear about it reading my earlier messages again. If we had needed to create something for a customer we could have rolled back the testing. Our usage of free instances should go down again after it is done.

[dentarg]

If you have paid instances, you now get a higher limit. I will close this issue because there is no action to take in this repo.

The API could give a better error message when this happens, but it is not high priority to address right now.