The underlying terraform-provider-infoblox provider creates the connector in the providerConfigure function that gets passed as ConfigureContextFunc in the ProviderSchema.
The idea would be that we create a cache for the connections created by the Infoblox Client, where the key is the ProviderConfigName or it's UID for further flexibility. In theory we could replace providerConfigure function with one that reads from the cache otherwise it creates a new connection with additional logic for invalidating the cookie every x minutes.
I am in the beginning phases of understanding the generated upjet code and how it interacts with the underlying provider, so any insight is helpful.
We have seen infoblox experience load issues when using auth credentials to proxy to other auth providers such as
duo proxy, same, etc
.The infoblox client seems to already support reusing a
connector
for multiple auth calls.It is supported to use the connection for multiple requests. In this case, authentication is handled by supplying the cookie (ibapauth) that was returned after the initial authentication. This cookie can be invalidated by sending a POST request to /wapi/v2.12.3/logout
The underlying terraform-provider-infoblox provider creates the connector in the
providerConfigure
function that gets passed asConfigureContextFunc
in the ProviderSchema.https://github.com/infobloxopen/terraform-provider-infoblox/blob/d9cc48b2a4c9154f5d3e0893eb0d404a20077888/infoblox/provider.go#L227
The idea would be that we create a cache for the connections created by the Infoblox Client, where the key is the
ProviderConfigName
or it'sUID
for further flexibility. In theory we could replace providerConfigure function with one that reads from the cache otherwise it creates a new connection with additional logic for invalidating the cookie every x minutes.I am in the beginning phases of understanding the generated upjet code and how it interacts with the underlying provider, so any insight is helpful.