This pull request implements #27, albeit suboptimally.
Currently it simply modifies the resources and data sources to store the LDAPProviderModel in the resource struct rather than the actual *ldap.Conn, and uses a helper, GetConn(), to connect and bind to LDAP during the Create/Read/Update/Delete operation.
While this succeeds in allowing lazy connection/binding to LDAP, it does mean a separate connection is established for every resource/datasource operation, which almost certainly incurs a performance penalty. I would prefer to use a global, static *ldap.Conn object which is created when the first resource/datasource needs to connect, and wraps accesses to it in a mutex, similar to how the Vault Terraform provider does it, but they're doing a lot of codegen to create their resources, so their changes don't really apply to this provider, and my familiarity with Go isn't sufficient for me to try to implement it myself at the moment.
Additionally, this would probably benefit from some added tests, but I'm unsure of the best way to go about that here. One possibility might be to use the docker Terraform provider to create the LDAP container in the integration test fixtures, rather than the docker-compose.yaml, which would have the added benefit of removing the step of manually running docker compose up on developer machines and using the compose-action step in the GitHub Actions workflow. I have successfully tested it myself locally however, in scenarios that previously did not work without lazy authentication.
This pull request implements #27, albeit suboptimally.
Currently it simply modifies the resources and data sources to store the
LDAPProviderModel
in the resource struct rather than the actual*ldap.Conn
, and uses a helper,GetConn()
, to connect and bind to LDAP during theCreate
/Read
/Update
/Delete
operation.While this succeeds in allowing lazy connection/binding to LDAP, it does mean a separate connection is established for every resource/datasource operation, which almost certainly incurs a performance penalty. I would prefer to use a global, static
*ldap.Conn
object which is created when the first resource/datasource needs to connect, and wraps accesses to it in a mutex, similar to how the Vault Terraform provider does it, but they're doing a lot of codegen to create their resources, so their changes don't really apply to this provider, and my familiarity with Go isn't sufficient for me to try to implement it myself at the moment.Additionally, this would probably benefit from some added tests, but I'm unsure of the best way to go about that here. One possibility might be to use the docker Terraform provider to create the LDAP container in the integration test fixtures, rather than the docker-compose.yaml, which would have the added benefit of removing the step of manually running
docker compose up
on developer machines and using thecompose-action
step in the GitHub Actions workflow. I have successfully tested it myself locally however, in scenarios that previously did not work without lazy authentication.I'll keep working on this when I have time!