Adding support for 'waiting until resource is ready' on create

[johanols]

This adds a feature where the provider waits until a resource is ready. To determine that two new schema parameters were added:

• create_ready_key
• create_ready_value

After creating the resource and if set, the object is repeatedly read and validated using these two parameters. As soon as the value corresponds to the resource value at key the provider will deem the resource ready and continue execution.

The default timeout for checking readiness is 10 minutes. Use Terraform's 'timeouts' argument to override.

Issue: https://github.com/Mastercard/terraform-provider-restapi/issues/33

[jonathan-kaufman-by]

This is awesome, and would be very useful to me.

[theochita]

Hi @johanols Can you fix the merge conflicts?, i made a conflict free branch of your code in my own repo can you can check out if it helps. https://github.com/theochita/terraform-provider-restapi/tree/johanols-feature/wait_for_ready_on_create

@DRuggeri Any thoughts on this feature?, it helps us be able to interface with async api's that returns an awaitable task, which should be polled every few sec until its finished.

[johanols]

I've fixed the merge conflicts now @theochita. I also adjusted the imports of resource to use v2 or the Plugin SDK. No need for any other adjustments. Tests ran through without any issues.

[fancybear-dev]

Would be amazing if the provider would support this!

[fancybear-dev]

Could this be merged? Would really appreciate it! cc @DRuggeri

[fancybear-dev]

fyi; we have forked and will maintain our changes at https://github.com/hnhdev/terraform-provider-restapi

Would still be great to see it merged, but at least we are not dependent anymore.

[fancybear-dev]

We ended up not using this PR, as it only supports create method. This is how we implemented it for our specific usecase (all CRUD functions supported, async);

https://github.com/hnhdev/terraform-provider-restapi/pull/7/commits/c023978fc0f2ef0c1d237ad328c9fe72a3acbbcc

[fgimenezm]

+1 to this feature. Looks like @johanols branch has conflicts now since it's been so long since he submitted the PR :-(

[DRuggeri]

Wow - I don't know how I haven't seen this PR until just now!!!! SO SORRY for the long delay - I've done several feature reviews since this was opened and dropped the ball!

I like this concept quite a bit because there are a number of APIs that are primarily async, but do have some reservations. As @fancybear-dev points out, it only supports the create operation, so we would need to have a think on what update and destroy should look like. I would surmise they look roughly the same. One area I am waffling a little is on the configuration parameters. There are a bunch of config params already in the provider and they seem potentially overwhelming for new users. Would it make sense to place these parameters in an asynchronous subkey to the provider to keep them "together" and hopefully less daunting to a new user?