Metaport_attachment. Root resource was present, but now absent.
James-Newman opened this issue · 5 comments
Logged error
module.xxx.metanetworks_mapped_service.mapped_service: Creation complete after 2s [id=ne-104]
module.xxx.metanetworks_mapped_service_alias.mapped_service_alias: Creating...
module.xxx.metanetworks_metaport_attachment.metaport_attachment: Creating...
module.xxx.metanetworks_policy.policy: Creating...
module.xxx.metanetworks_mapped_service_alias.mapped_service_alias: Creation complete after 0s [id=ne-104_xxx]
Error: Provider produced inconsistent result after apply
When applying changes to
module.xxx.metanetworks_metaport_attachment.metaport_attachment, provider
"registry.terraform.local/mataneine/metanetworks" produced an unexpected new
value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Steps to reproduce
Unknown. I can't force this to occur, only that is has now and terraform can't provision any metaport_attachment resources.
I suspect the error being thrown is from resource_metaport_attachment.go line 55. If I manually attach the metaport_service to the metaport, then the condition on resource_metaport_attachment.go line 47 triggers, which suggests to me that the error is encountered after this.
The attachment however does happen, and I can see this reflected in the metanetworks UI. Possibly the api is returning an error that the mapped_service is already attached?
is this still an issue? If so can you please post your config files (tfvars, tf or hcl (if using terragrunt)) so I can have a look at what might be triggering it?
Hey @jmohr01 apologies for the late reply. The problem is actually with the provider with the logs you can see wy we get that error.
module.adam.metanetworks_metaport_attachment.metaport_attachment: Creating...
2021/05/04 17:16:55 [DEBUG] EvalApply: ProviderMeta config value set
2021/05/04 17:16:55 [DEBUG] module.adam.metanetworks_metaport_attachment.metaport_attachment: applying the planned Create change
2021-05-04T17:16:55.129Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Locking "": timestamp=2021-05-04T17:16:55.129Z
2021-05-04T17:16:55.129Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Locked "": timestamp=2021-05-04T17:16:55.129Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Response: {
"allow_support": true,
"connection": {
"connected": true,
"connected_at": "2021-04-25T04:52:06Z",
"disconnected_at": "2021-03-18T09:43:15Z",
"location": "AMS",
"src_underlay_ip": "34.91.5.104",
"vpn_proto": "ipsec"
},
"created_at": "2020-12-20T12:34:54.538Z",
"description": "",
"dns_name": "6.36020.nsof",
"enabled": true,
"expires_at": "2023-12-20T12:35:25.488Z",
"health": "healthy",
"id": "mp-6",
"mapped_elements": [
"ne-9",
"ne-17",
"ne-18",
"ne-20",
"ne-23",
"ne-25",
"ne-26",
"ne-27",
"ne-28",
"ne-33",
"ne-35",
"ne-36",
"ne-45",
"ne-46",
"ne-47",
"ne-48",
"ne-49",
"ne-50",
"ne-55",
"ne-61",
"ne-62",
"ne-64",
"ne-73",
"ne-76",
"ne-90",
"ne-104",
"ne-109",
"ne-111"
],
"modified_at": "2021-05-04T17:15:58.094Z",
"name": "metaport-workstations",
"notification_channels": [],
"org_id": "org-36020"
}: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Returning Metaport from Get: mp-6: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Field Name Name with metaport-workstations: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Field Name Description with: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Field Name Enabled with <bool Value>: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Update Field Name AllowSupport with <*bool Value>: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.141Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Field Name MappedElements with <[]string Value>: timestamp=2021-05-04T17:16:55.141Z
2021-05-04T17:16:55.290Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Response: {
"allow_support": true,
"created_at": "2020-12-20T12:34:54.538Z",
"description": "",
"dns_name": "6.36020.nsof",
"enabled": true,
"expires_at": "2023-12-20T12:35:25.488Z",
"health": "healthy",
"id": "mp-6",
"mapped_elements": [
"ne-9",
"ne-17",
"ne-18",
"ne-20",
"ne-23",
"ne-25",
"ne-26",
"ne-27",
"ne-28",
"ne-33",
"ne-35",
"ne-36",
"ne-45",
"ne-46",
"ne-47",
"ne-48",
"ne-49",
"ne-50",
"ne-55",
"ne-61",
"ne-62",
"ne-64",
"ne-73",
"ne-76",
"ne-90",
"ne-104",
"ne-109",
"ne-111",
"ne-116"
],
"modified_at": "2021-05-04T17:16:55.184Z",
"name": "metaport-workstations",
"notification_channels": [],
"org_id": "org-36020"
}: timestamp=2021-05-04T17:16:55.290Z
2021-05-04T17:16:55.290Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Returning Metaport from Update: mp-6: timestamp=2021-05-04T17:16:55.290Z
2021-05-04T17:16:55.290Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Locking "mp-6_ne-116": timestamp=2021-05-04T17:16:55.290Z
2021-05-04T17:16:55.290Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Locked "mp-6_ne-116": timestamp=2021-05-04T17:16:55.290Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Response: {
"allow_support": true,
"connection": {
"connected": true,
"connected_at": "2021-04-25T04:52:06Z",
"disconnected_at": "2021-03-18T09:43:15Z",
"location": "AMS",
"src_underlay_ip": "34.91.5.104",
"vpn_proto": "ipsec"
},
"created_at": "2020-12-20T12:34:54.538Z",
"description": "",
"dns_name": "6.36020.nsof",
"enabled": true,
"expires_at": "2023-12-20T12:35:25.488Z",
"health": "healthy",
"id": "mp-6",
"mapped_elements": [
"ne-9",
"ne-17",
"ne-18",
"ne-20",
"ne-23",
"ne-25",
"ne-26",
"ne-27",
"ne-28",
"ne-33",
"ne-35",
"ne-36",
"ne-45",
"ne-46",
"ne-47",
"ne-48",
"ne-49",
"ne-50",
"ne-55",
"ne-61",
"ne-62",
"ne-64",
"ne-73",
"ne-76",
"ne-90",
"ne-104",
"ne-109",
"ne-111"
],
"modified_at": "2021-05-04T17:15:58.094Z",
"name": "metaport-workstations",
"notification_channels": [],
"org_id": "org-36020"
}: timestamp=2021-05-04T17:16:55.302Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 Returning Metaport from Get: mp-6: timestamp=2021-05-04T17:16:55.302Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Unlocking "mp-6_ne-116": timestamp=2021-05-04T17:16:55.302Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Unlocked "mp-6_ne-116": timestamp=2021-05-04T17:16:55.302Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Unlocking "": timestamp=2021-05-04T17:16:55.302Z
2021-05-04T17:16:55.302Z [INFO] plugin.terraform-provider-metanetworks: 2021/05/04 17:16:55 [DEBUG] Unlocked "": timestamp=2021-05-04T17:16:55.302Z
2021/05/04 17:16:55 [DEBUG] module.adam.metanetworks_metaport_attachment.metaport_attachment: apply errored, but we're indicating that via the Error pointer rather than returning it: Provider produced inconsistent result after apply: When applying changes to module.adam.metanetworks_metaport_attachment.metaport_attachment, provider "registry.terraform.local/mataneine/metanetworks" produced an unexpected new value: Root resource was present, but now absent.So from this logs you can see that we do an API call in the first instance and we have 28 mapped_services. On the second call to the API we can see that we have 29 mapped services a new was added the ne-116.
A thrid call is done and possibly does a diff between second call and third call, and there's where we get the issue. If you go to the UI we end up seeing that ne-116 was actually mapped.
We also got an answer from metanetworks regarding this issue:
Our API is eventually consistent.
When you do a change on an object and the REST call succeeds the change will be reflected on the returned object of the same call. However, if you issue a GET call immediately after, there is a small period of time in which the returned object may be in its previous state.
In your specific case, a network element is attached to a metaport, and the call succeeds.
However, a GET call which is issued immediately affect PATCH returns the metaport in its previous state. So TF fails. The solution to this issue is to poll the object until it returns the newly added network element. An example for such scheme may be seen in the implementation of the AWS TF provider.
ping @jmohr01
Hi, Thank you for your investigation regarding this issue. It reduce the time that took us to solve the problem #76 .