Utilize multiple APICs to loadbalance the load when building many resources in ACI (DCNE-118)

[JockeW-DvL]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I am using terraform for a couple of ACI implementations, and would like to be able to spread the load of depolying resourses via terraform in multiple APICs, i.e. have multiple APIC URLs in the provider config and spread the deployment over all APICs specified.

New or Affected Resource(s) + ACI Class(es):

• aci_XXXXX + fv:XXXX

APIC version and APIC Platform

• V x.x.x and on-prem/cloud-aws/cloud-azure/all.

Potential Terraform Configuration

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

• #0000

[lhercot]

Hi @JockeW-DvL , thanks for opening this enhancement request. Feedback from our user community is always welcomed.

This proposal is more complicated than simply allowing to spread request over multiple APICs as the internal structure of the APIC cluster is already a distributed architecture. Which means that when you push a change to an APIC (lets say APIC1) it might be redirected to another APIC (APIC2). This behavior is based on the internal sharding mechanism of the APIC database where each APIC is master of a portion of the shards.

This means that by spreading the load to multiple APICs you might at the end still send all writes to the same APIC if those objects you manipulates are all in the same shard.

On the other hands, this adds quite a bit of complexity in the provider, the go client and in the troubleshooting if something goes wrong.

I will keep this enhancement request open to see if other want to chime in in favor but for now this feature request will not be on the top of our list.

[JockeW-DvL]

body{font-family:Helvetica,Arial;font-size:13px}Hello All,Thanks for the explanation of how it works with ACI and APICs. I understand that it would be very hard to implement what I was asking for.With he way you described how it works then we don’t need to actually do what I’m requesting in this feature request.Regards On 13 December 2021 at 17:15:56, Lionel Hercot @.***) wrote: Hi @JockeW-DvL , thanks for opening this enhancement request. Feedback from our user community is always welcomed. This proposal is more complicated than simply allowing to spread request over multiple APICs as the internal structure of the APIC cluster is already a distributed architecture. Which means that when you push a change to an APIC (lets say APIC1) it might be redirected to another APIC (APIC2). This behavior is based on the internal sharding mechanism of the APIC database where each APIC is master of a portion of the shards. This means that by spreading the load to multiple APICs you might at the end still send all writes to the same APIC if those objects you manipulates are all in the same shard. On the other hands, this adds quite a bit of complexity in the provider, the go client and in the troubleshooting if something goes wrong. I will keep this enhancement request open to see if other want to chime in in favor but for now this feature request will not be on the top of our list.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.