root_parent_id fails validation during level1/eslz deploy

[Justin-DynamicD]

bit of a journey to get there, but hopefully this is clear.

During the ignite phase, documentation asks that you modify one of the existing definitions/platform folders with desired settings. In particular the following file has the following section/comment:

file: definitions/platform/reuse_subscriptions/contoso.caf.platform.yaml

    # Option only set if you've be given a delegated management group ID.
    # Comment to deploy to deploy at the tenant root level
    root_parent_id: lab

the implication is that during deployment, I should be able to comment out (#) the root_parent_id and the enterprise management group structure will deploy to root.

performing the ignite works correctly. However, when attempting to plan/apply each level:

• level0/platform - good
• level1/management - good
• level1/eslz - failed during plan

output error:

│ Error: Invalid value for variable
│ 
│   on variables.tf line 88:
│   88: variable "root_parent_id" {
│ 
│ The root_parent_id value must be between 2 to 10 characters long and can only contain alphanumeric characters and hyphens.
│ 
│ This was checked by the validation rule at variables.tf:93,3-13.
╵
Terraform plan return code: 1
Error on or near line 391: Error running terraform plan; exiting with status 1

If, instead of commenting out root_parent_id I use "root", the plan will pass, but during deployment it will error that it cannot find a management group with said name. Any attempt to use the actual ID or name of the root management group will error as both exceed 10 characters.

Additional Info:

landingzones git is set to aci_network branch

[arnaudlh]

hi @Justin-DynamicD, feels like this might solve your issue: https://github.com/Azure/caf-terraform-landingzones/commit/21f42247ee88875d51ea45666cff8ce79028e4a2 :)

[Justin-DynamicD]

I was literally just about to update that removing the validation solved the problem, as it was blocking "null" as a valid option. Sorry for putting this issue in the wrong repo after all that, but I wasn't certain if the issue was with the ansible assembly or the module.

Will close.