Handing Resource Count?

Terraform Providers Plugin Development
1

I’m developing a resource that gets an available IP from an IPAM system.

The backend method call gets the first item with a status of “Available” and marks it as “Used”

The problem I have is that when I try to create multiple instances of this object, creation seems to happen in parallel. The result is that I get two resources with the same IP…

How can I implement logic for the resource based on the “count” passed in?

2

It will happen in parallel unless the ‘parallelism’ setting in Terraform is set to ‘1’ (it defaults to ‘10’).

If the API operations to your IPAM are not atomic, then you’ll probably have to implement some sort of synchronization inside the provider to ensure that there is only one request active at a time. A sync.Mutex would be straightforward to use for this.

Locking to avoid multiple like resources being created concurrently?
3

You can use MutexKV helper provided by the SDK to serialize changes made by your provider.

4

It’s not immediately clear to me how sync.Mutex helps here? Any chance you could point to an example?

5

The MutexKV docs referred to by @gordonbondon says that the AWS provider uses it to serialize requests for AWS EC2 security groups, so that’s probably a good example.

Essentially you’ll use the Mutex to ensure that a single block of code (the one where the IPAM ‘IP Address request’ is made) can only be executed by a single goroutine at a time.

6

Fascinating. Gonna have to look up how exactly the defer keyword works and make sure I implement properly. Looks pretty straightforward though.

Just in case anyone comes across this…

Usage shown here and the mutex object is declared globally in the provider.go

Thanks for the response @kpfleming @gordonbondon!

1 Like
7

FYI mutexkv is gone from recent versions of the v2 SDK, so the way to do it is:

import (
    "sync"
)

var myMutex  sync.Mutex

func foobar() {
    myMutex.Lock()
    // ...
    myMutex.Unlock()
}

Actually, all mutexkv was was a handy wapper around that to provide a map of multiple sync.Mutexs behind a string key. So, useful maybe, but not necessary and easily replicable. (Presumably that’s why it was removed!)

Unfortunately it was only after I’d worked this out that I discovered the third-party API I was using had changed, and I no longer need it, but maybe it’ll help someone else, or future me! :smiley:

Locking to avoid multiple like resources being created concurrently?