Provisioning API interface is bad, docs are wrong/not helpful
That you can provide a name for utility instances and deprovision by name, but for app instances you have to deprovision by Amazon ID adds too much unnecessarily complexity.
We just wrote a scaling tool to provision/deprovision app and utility instances on a schedule. This was pretty easy to do for utility servers, we have a database table with the name, environment, and role of the machines we provision, so we can just grab one and use its name to deprovision it.
However, for app servers, we have to query the environments, search through the returned JSON for an instance ID, then call deprovision. We also can't easily tie back which machine was deprovisioned to our database table. I don't understand why you have this discrepancy.
Then there are other things like "provisioned_id" is the field we can pass in, yet in the environments response that value is called "amazon_id." That should be consistent and probably just provisioned_id to be agnostic to the cloud host. I also suggest that you all update the documentation to include how to actually deprovision app instances, and include things like that the body needs to be in a container called "request" which is not obvious unless you read the curl example. I only found out about provisioned_id after sending in a ticket asking how to use the deprovision API for app servers.
Please sign in to leave a comment.