microscopic-park-81177
07/28/2023, 3:16 PMechoing-dinner-19531
07/28/2023, 3:25 PMmicroscopic-park-81177
07/28/2023, 3:25 PMechoing-dinner-19531
07/28/2023, 3:25 PMmicroscopic-park-81177
07/28/2023, 3:38 PMechoing-dinner-19531
07/29/2023, 8:04 PMrhythmic-sunset-53997
07/31/2023, 10:01 AMhave you tried putting a mutex in your dynamic provider’s create / update functions?Yes, I tried these:
I tried using the standard threading Python library, but this doesn’t seem to work, the requests are made concurrently. Also no luck with fasteners.To my surprise, neither worked - I added some
sleep()
calls and from the logs it was clear that all of the resource creation “threads” obtain the mutex at approx. the same time. Which is odd, because the latter library is supposed to support inter-process file-based locking. So either the library is bugging out or something really odd is happening.
At that point I decided to ask here if there is a better, recommended approach for this.
I find that the official/supported providers are quite nice to work with in Pulumi, but adding anything custom (which I understand Dynamic providers are for) is clunky. I wonder if I am missing something, or is the “custom extensibility” more of a nice-to-have-sidethought that doesn’t have much use? (No offense here, it’s perfectly okay to not support that - I just want to decide whether I should stop trying 😁 )echoing-dinner-19531
07/31/2023, 3:32 PMmore of a nice-to-have-sidethought that doesn’t have much useIt's more that it's a lot of work to support this well and we haven't had time. It would be lovely for dynamic providers to just work and for it to be easier to write native providers, but we just haven't had the capacity to work on them. In this case what I think is happening is that the dynamic provider "re-hydrates" your provider code for every resource method call, so if you make a mutex object it's only actually shared for that one resource call. That's why I suggested using a named mutex, because then the state is stored in the operating system itself.