please consider ignore order difference when apply

[fsdrw08]

currently there is different terraform plan result when the attribute list order is difference from target ldap server, I had to make the order of value in the list match with the ldap server objectClass = ["inetOrgPerson", "organizationalPerson", "top", "person"] ->
objectClass = ["top", "inetOrgPerson", "organizationalPerson", "person"]

 resource "ldap_entry" "svc_readonly" {
      ~ data_json = jsonencode(
          ~ {
              ~ objectClass  = [
                  - "top",
                    "inetOrgPerson",
                    "organizationalPerson",
                  + "top",
                    "person",
                ]
                # (3 unchanged attributes hidden)
            }
        )

[l-with]

@fsdrw08 I understand the situation, but not the terraform flow you are using: Do you create the ldap entry with terraform and then change the order of the attributes or do you import the resource with terraform or do you use another way?

[fsdrw08]

@fsdrw08 I understand the situation, but not the terraform flow you are using: Do you create the ldap entry with terraform and then change the order of the attributes or do you import the resource with terraform or do you use another way?

I create ldap entry with this provider:

resource "ldap_entry" "svc_readonly" {
  dn = "uid=readonly,ou=Services,${var.base_dn}"
  data_json = jsonencode({
    objectClass  = ["person", "inetOrgPerson", "organizationalPerson", "top"]
    userPassword = ["{SSHA}k/8CkwU7/1C/QM+Qw2uNkOqzOQxdv2qLwQ=="]
    cn           = ["readonly"]
    sn           = ["readonly"]
  })
}

In the first time apply, it will shows 1 resource added.
Then , without any change, apply the same code again after the first apply, terraform will shows

resource "ldap_entry" "svc_readonly" {
      ~ data_json = jsonencode(
          ~ {
              ~ objectClass  = [
                  - "top",
                    "inetOrgPerson",
                    "organizationalPerson",
                  + "top",
                    "person",
                ]
                # (3 unchanged attributes hidden)
            }
        )

this difference information will shows again and again if I don't re-arrange the list

This difference information will only disappear until I re-arrange the list from
["inetOrgPerson", "organizationalPerson", "top", "person"] to ["top", "inetOrgPerson", "organizationalPerson", "person"]

[l-with]

I create ldap entry with this provider:

resource "ldap_entry" "svc_readonly" {
  dn = "uid=readonly,ou=Services,${var.base_dn}"
  data_json = jsonencode({
    objectClass  = ["person", "inetOrgPerson", "organizationalPerson", "top"]
    userPassword = ["{SSHA}k/8CkwU7/1C/QM+Qw2uNkOqzOQxdv2qLwQ=="]
    cn           = ["readonly"]
    sn           = ["readonly"]
  })
}

In the first time apply, it will shows 1 resource added. Then , without any change, apply the same code again after the first apply, terraform will shows

resource "ldap_entry" "svc_readonly" {
      ~ data_json = jsonencode(
          ~ {
              ~ objectClass  = [
                  - "top",
                    "inetOrgPerson",
                    "organizationalPerson",
                  + "top",
                    "person",
                ]
                # (3 unchanged attributes hidden)
            }
        )

this difference information will shows again and again if I don't re-arrange the list

This difference information will only disappear until I re-arrange the list from ["inetOrgPerson", "organizationalPerson", "top", "person"] to ["top", "inetOrgPerson", "organizationalPerson", "person"]

I tried this with provider version 0.5.6 and openldap. The result is

No changes. Your infrastructure matches the configuration.

Please help me to reproduce the situation with more informations (since version 0.4.2 of the provider the ldap entry resource is loaded again after creating).

[fsdrw08]

I use opendj, you can run it via docker, here is a docker compose example, ref: OpenDJ Preparation

  opendj:
    image: openidentityplatform/opendj:latest
    hostname: opendj.example.com
    ports:
      - "1389:1389"
      - "1636:1636"
      - "4444:4444"
    volumes:
      - ./opendj/bootstrap/data/:/opt/opendj/bootstrap/data #initial data
      - ./persistence/opendj:/opt/opendj/data #opendj data
    environment:
      - BASE_DN=dc=openidentityplatform,dc=org #should be yours base DN

the ldif of initial data in my case

dn: ou=Services,dc=openidentityplatform,dc=org
objectClass: organizationalunit
objectClass: top
ou: Services
aci: (targetattr = "*")(version 3.0; acl "Service account self modification denied for all attributes"; deny (write) userdn ="ldap:///self";)

after docker-compose up, run the terraform to apply ldap entry
provider information:

provider "ldap" {
 ...

  bind_user     = "cn=Directory Manager"
  bind_password = "password"
}

resource "ldap_entry" "svc_readonly" {
  dn = "uid=readonly,ou=Services,${var.base_dn}"
  data_json = jsonencode({
    objectClass  = ["person", "inetOrgPerson", "organizationalPerson", "top"]
    userPassword = ["{SSHA}k/8CkwU7/1C/QM+Qw2uNkOqzOQxdv2qLwQ=="]
    cn           = ["readonly"]
    sn           = ["readonly"]
  })
}

after applied, re-apply again

[l-with]

Before I start testing with OPenDJ, please check the provider version you are using. This is my .terraform.lock.hcl:

# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.

provider "registry.terraform.io/l-with/ldap" {
  version     = "0.5.6"
  constraints = "~> 0.5"
  hashes = [
    "h1:SLmZ4T+jg7yeB8kiCbaZ26YS8Jo9TI9KMdAPgsJiHnU=",
    "zh:0e176bfbf1f675bfb6a9b686951e3d9811a3932ec4149791d82189fb322916f8",
    "zh:29cab57ba47e2ea946e13394afa292852c1d33d24dad568ef414c7ad50e01d35",
    "zh:346fbc9ce61ce47b32fb19b2fc222b88df5e9443f8e576c593ac39545753b704",
    "zh:52e037dc9fead3a26f05f012c25a6f4f0f84cbac27d1996e84cc3c3880952a49",
    "zh:6770697a9430607aa75c7daf5e37e93f986468e83d9478f55ef998fee5db083b",
    "zh:677724b38719314bd99a34383f33f101540b01f0b98af97fa40ec5e9180d327b",
    "zh:843e0db58d8cd9a056865e240bd13bde64c23e27d993a997647e02e9c745fd2f",
    "zh:8b6aebfbdae2a95bef20c922eb574990cbe0fd31e5d40858a0fd9aa90a035ce2",
    "zh:971b372717d9133e608833d54205766e453476cca2a7f1a2394d3895390e2329",
    "zh:c5ed0977f983066d894dc80585a668a8f95ae1c4f4780fff57291dbc2e81d6c6",
    "zh:c85ab2957e1cc5b17f70fb30685b06d3d40419fdfc4a060e005fec7d2378c3f0",
    "zh:f569b65999264a9416862bca5cd2a6177d94ccb0424f3a4ef424428912b9cb3c",
    "zh:f645f58421ca66eb4f4ce2240375d6a5dca3dcafe8bf7d9895131cc22384d383",
    "zh:fa18a66dc024e4a715b51bd763e57529418cfac8ecab0b0c3b821cb3ba0d17c3",
    "zh:fcdfb779ecc8db5d345c236349899a3a681753a7b0c5feda50f25a3626597e9b",
  ]
}

[fsdrw08]

yes, I am using the latest version of this provider

provider "registry.terraform.io/l-with/ldap" {
  version     = "0.5.6"
  constraints = ">= 0.5.6"
  hashes = [
    "h1:cqTRL6dknCj0b6yLFX+4ZNFFMnuqbpJ0PcAaE6smQ0k=",
  ]
}

[l-with]

should be fixed in version 0.6.0