apstra_datacenter_device_allocation - device profile issue

[pyspiotr]

Hello,
I got an error once using apstra_datacenter_device_allocation resoruce in Apstra 4.2.1.
Attached files consist of the output I got after apply.
The error does not show up if the device_key is not specified.
Regards,
Piotr

[chrismarget-j]

Hi @pyspiotr,

Thank you for opening this issue.

Would you mind sharing a sample of the terraform configuration which was being applied in this case?

[pyspiotr]

terraform_apstra_lab.zip
Hi Chris,
Here is the LAB setup in which you may use to replicate the issue. There are 2 steps included:

1. Initial phase - we build a blueprint with dummy RACK and resources.
2. Second phase - extension of the existing blueprint - new RACKs, Leafs ....
   If we you uncomment the "#device_key = each.value.device_key" in blueprint.tf you will see the error described ealier.
   Regards,
   Piotr

[chrismarget-j]

Hi @pyspiotr,

Having two graph nodes with the same device_profile_id is a surprise for us. We've got some theories about what might be going on, but would like to take a closer look at the state of your system.

Would you please open a case with Juniper/Apstra TAC and share the "show tech" and a backup from your environment so we can investigate further? The TAC folks can walk you through it.

Thanks!

[chrismarget-j]

Hi @pyspiotr,

We've managed to reproduce the condition in a test environment. We may not need the data from your system.

I'll keep you posted.

[chrismarget-j]

Update: I'll summarize my current understanding of the situation here.

• Having two identical Device Profile nodes (clones) in Apstra's graph DB is an unexpected condition.
• The presence of clones does not present any operational risk to an Apstra managed fabric.
• Previous versions of Apstra had issues when upgrading Blueprints which included clones.
• Apstra support can help with a process to eliminate them.
• Current Apstra releases may introduce clones when a rack is imported into an existing blueprint under the following conditions:
  • The rack includes a Logical Device which does not currently exist in the Blueprint.
  • An interface Map which references that Logical Device is available in the Catalog
  • That Interface Map does not appear in the Blueprint
  • That interface Map references a Device Profile which does appear in the Blueprint.
• A fix to the rack import logic will be incorporated into a future Apstra release so that clones will no longer be created under these circumstances.
• The terraform provider naively assumes that clones will not exist in the graph DB.
• We'll update the terraform provider so that clones are handled seamlessly.

You may be able to work around the problem by including an example of each Logical Device in the racks which comprise the Template from which the Blueprint is initially created (so that no rack import introduces a new LD), or by proactively importing the required Interface Map prior to import of the new racks.

We'll update this issue when the terraform provider includes a fix for seamless handling of the clones.

[pyspiotr]

Works perfect! Thx a lot.