Support aws_connection import

[angryninja48]

Trying to import an AWS hosted connection:

Error: resource megaport_aws_connection doesn't support import

[pedrojflores]

+1

I need this functionality as well. We already have an existing AWS Megaport infrastructure and the ability to import it is crucial for us to be able to leverage this provider.

[txraider09]

+1

We need to ability to import as well.

[7jPUn4w8caDX]

+1 Very important to be able to import existing Megaport / AWS Infrastructure

[steve-exley]

We are tracking requests for this. It was in the original releases and got taken out due to reliability issues. Currently we're resolving some other edge cases but this is on the roadmap. Thanks

[jpenaq2]

+1

[ngarratt]

The issue here looks to be on the API, so not fixable in the provider.

I only see six attributes for csp_connection being returned by the /v2/product[s] endpont, but the following don't appear to be exposed anywhere after the VXC has been created:

• requested_asn
• amazon_asn
• auth_key
• prefixes
• customer_ip
• amazon_ip

Those are all ForceNew in the schema. So without them you could import the connection but the next apply will force a destroy and recreate.

Are there any plans to expose the missing elements on one of the endpoints?

[ngarratt]

My mistake here. API is returning CSP details, but only those that are valid for the specific VXC type. Would be helpful if the API documentation included request/response parameter details, and not just a handful of examples that are no longer accurate.

Aside from some (solvable) attribute consistency issues if invalid attributes are provided for the type of VXC, the one piece of information we're actually missing is requested_product_id. I would expect to be able to get that from the B-end, but that doesn't work with VIFs (only the HC I was looking at). It looks like you validate/buy against a one ProductID, but your VIF is fulfilled from a different pool of ProductIDs. So that mismatch would cause a ForceNew

[steve-exley]

The API returning a different Product ID to the order is a known API quirk. It relates to the Megaport platform having parallel identical connections "Products" on popular paths. The backend will spread orders over all available connections rather than favouring the one in the order request. What you see in the VIF response is the real product ID which may be the same or different to the order request.

Unfortunately this functionality was not designed into the original API and it now it retains this behaviour to be backward compatible. It does make Terraform for Megaport a little bit harder.

[ngarratt]

Looking just at the API data, it appears the design is to have multiple products with identical product+type+location+company. One is set for vxcPermitted=true (the product that can be ordered) and the rest false (where they're actually fulfilled from). On the backend you then transparently select from one of those equivalent products if the specified product is at capacity.

So added pull/25 to populate csp_settings on import, and match to the orderable product. Same algorithm as dataMegaportPartnerPortRead, so these should be consistent during the import and first plan.

[dannybarnes]

Now working in v0.2.4