DXE-2720 Deactivations of cloudlet return immediately, while processing is still happening in the background

[hypnotisttom]

Hi,

For cloudlets, I'm trying to run these steps with terratest:

1. Create cloudlet
2. Activate cloudlet
3. Deactivate cloudlet
4. Delete cloudlet

The deactivation is kicked off and completes in the TF (albeit taking only 2s); however, I suspect the TF is returning before the deactivation is complete, because when performing a delete after, I get this:

╷
│ Error: Unable to remove policy
│ 
│ Policy could not be removed because some activations are still pending. Please try again later.
╵
exit status 1

I am attempting to add wait times in the terratest, although that is not ideal. I notice that in akamai_gtm_property there is a wait_on_complete option. I am wondering if we can have something similar for the deactivation of the cloudlet, so that it continues to run in the TF until it is actually complete.

Sidenote: The error message was slightly confusing, as it wasn't an activation that is pending, but rather a deactivation.

Thanks,

Tom

[dawiddzhafarov]

Hi @hypnotisttom

Thank You for opening the issue. I can confirm that it is valid and we will be working on resolving it.

With regards,
Dawid

[majanpaul]

not sure if its related to this ..

but upgrading to 5.0 i keep getting this error

akamai_cloudlets_policy.request_control_1: Creating...
╷
│ Error: create policy: API error: 
│ {
│ 	"type": "https://problems.luna.akamaiapis.net/-/pep-authn/deny",
│ 	"title": "Not authorized",
│ 	"detail": "The signature does not match",
│ 	"instance": "https://akab-xxx-knvindwkeriidf42.luna.akamaiapis.net/cloudlets/api/v2/policies",
│ 	"statusCode": 401
│ }
│ 
│   with akamai_cloudlets_policy.request_control_1,
│   on cloudlet-request-control.tf line 1, in resource "akamai_cloudlets_policy" "request_control_1":
│    1: resource "akamai_cloudlets_policy" "request_control_1" {

downgraded to - Installing akamai/akamai v4.1.0...

the error went away ..

i read something about the HTTP client following the 303s without getting a new auth token.

https://community.akamai.com/customers/s/question/0D50f00006KQkd0CAD/how-to-resolve-the-signature-does-not-match-401-error-when-making-calls-to-the-diagnostic-tools-api-v2-to-check-the-status-of-asynchronous-requests?language=en_US

[mgwoj]

Please see #444 (comment) and workaround for this problem #444 (comment)

[lkowalsk-akamai-com]

This issue was fixed in 5.0 release

[hypnotisttom]

Hi @lkowalsk-akamai-com,

I'm still seeing the deactivation return immediately.

The difference I'm seeing this time is it appears the cloudlet delete is waiting for the deactivation to complete prior, which solves the error message.

This does get me further along in my test writing; we probably should have deactivation wait for completion though, as there are times where we will want to deactivate without removing as part of the enterprise pipeline.

Please let me know if you are seeing a different behavior on your side.

Thanks,

Tom

[hypnotisttom]

One follow-up to that: when running the delete to perform the deactivation, I'm getting:

╷
│ Error: retry timeout reached: context deadline exceeded
│
│
╵
exit status 1

Looks like it was running for 20 minutes before erroring out.

[mgwoj]

We will investigate it further under DXE-2991