Friday, June 16, 2023

My corrected OCI-IAM-compartment Terraform Module

How to Get the Latest OS Image in Oracle Cloud Infrastructure (OCI) using  Terraform | by Guillermo Musumeci | Medium

  Oracle Logo


So, turns out I've been living in the Stone Age of Terraform. I thought keeping my code lean and mean was the way to go, but apparently, the cool kids are all about terraform modules. They're all like, "Modularity! Reusability! It's the secret sauce of Infrastructure as Code!". Up until now, with my resources being simple, I learned to just leverage dynamic blocks (for_each) or variable interpolations through locals to keep it light, but not for long it seems.

Are Modules just hype or a real necessity ?

This is what I wanted to figure after getting my HashiCorp certification to see what all the hype was about.
And for that, I picked a simple OCI Iam module available in the terraform registry of Oracle provider

What’s wrong with the OCI IAM module anyway ?

Just like any software, Terraform is constantly evolving. Staying up to date with the latest versions is crucial, as new releases can bring significant changes to the syntax and supported attributes. Failing to proof your code against these updates could break your stack. This applies to Terraform modules maintainers too (Oracle TF Modules).

GitHub - oracle-terraform-modules/terraform-oci-iam: Terraform Module for  managing Oracle Cloud Infrastructure Identity and Access Management (IAM)  resources

The module in question is iam-compartment under:


t the time of my correction back in Feb, the following errors were not fixed and I was too lazy for a pull request, hence my local module creation. Fortunately for OCI users, recent fixes were added to the iam module.
                                                               I didn’t try it yet but feel free to do so.

1. Duplicate Required providers configuration ( &


I faced this `iam-compartment` issue with Terraform v1.0.3 but it occurs even with v0.13. Right from the init step.
# terraform init

Initializing modules... Downloading oracle-terraform-modules/iam/oci 2.0.2 for iam_compartment_x... - iam_compartment_x in .terraform/modules/iam_compartment_x/modules/iam-compartment There are some problems with the configuration, described below. The Terraform configuration must be valid before initialization so that Terraform can
determine which modules and providers need to be installed.
Error: Duplicate required providers configuration │ on .terraform/modules/iam_compartment_x/modules/iam-compartment/ line 2,
| in terraform: │ 2: required_providers {.. │ A module may have only one required providers configuration.
| The required providers were previously configured at
.terraform/modules/iam_compartment_x/modules/iam-compartment/ : line 5,3-21

CAUSE:  See issue #33 

  • In the above error terraform complains that the required_provider block was defined twice

    • => line 2  &  => line 5

This image has an empty alt attribute; its file name is image-3.png

: In 2022 Oracle moved their terraform provider out of HashiCorp which led to the introduction of required_provider block, to update oci provider source to "oracle/oci". 


    Only keep one required_provider block in the compartment module (i.e:  over

    # vi ~/modules/iam-compartment/

    terraform { required_providers { oci = { source = "oracle/oci" <---- Provider maintained/hosted by Oracle not Hashicorp version = ">=4.67.3" } } required_version = ">= 1.0.0" }

    2. Deprecated list and map function calls from iam-compartment


    Another issue due to deprecated functions (list/map) that were no longer supported by terraform
    .. compartment_ids = concat(flatten(data.oci_identity_compartments.this.*.compartments), list(map("id", ""))) …

    Error >
    │ Call to function "list" failed: the "list" function was deprecated in │ Terraform v0.12 and is no longer available; use tolist([ ... ]) syntax to │ write a literal list.

    Error >
    │ Call to function "map" failed: the "map" function was deprecated
    | in Terraform v0.12 and is no longer available; use tomap({ ... }) syntax to
    | write a literal map.

    CAUSE:  See issue #27 

    • As described in the docs, list() and map() function are deprecated in v012 & removed in v015 (read here)


      Terraform can infer the necessary type conversions automatically from context. In those cases, you can just use the [...] or {...} syntax directly, without a conversion function.

      Another option would be to just convert the functions into their new equivalent (map=> tomap, list=>tolist).

      Example: line 27-28

      --- Before
      compartment_ids = concat(flatten(data.oci_identity_compartments.this.*.compartments),
      list(map("id", "")))

      --- Option 1
      compartment_ids = concat(flatten(data.oci_identity_compartments.this.*.compartments),
      [{ id = "" }])

      --- Option2 : using tomap and tolist

      compartment_ids = concat(flatten(data.oci_identity_compartments.this.*.compartments),
      tolist( [tomap({"id" = ""})]))

      My corrected version (local module)

      It was easier to create a corrected version in my git repo that you can use locally. see folder iam-compartment

      This image has an empty alt attribute; its file name is image-4.png

      How to call it

      Same as if you would for the official registry module (oracle-terraform-modules/terraform-oci-iam)

      module "My_compartments" { source = "./modules/iam-compartment" #tenancy_ocid = var.tenancy_ocid # optional compartment_id = var.comp_id # Parent compartment compartment_name = var.comp_name compartment_description = var.comp_description compartment_create = true enable_delete = true }

      What you need to know about modules

      • Registry modules

        • One single resource block per module: you’ll have as many folders as module blocks

        • Even if you use for_each loop say i=10, you will have 10 downloads under .terraform folder

        • You depend on the maintainers good will for code sanity/integrity checks

      • Local modules

        • Reuse a single instance of the module for all your module calls, including dynamic blocks

        • Code proofing responsibility against new updates falls on you


      • This goes to show how important it is to keep the code up to date & compatible especially for tf modules

      • Whether you choose a local or 3rd party module, there are positives and negatives as with all things.

      • Due diligence is always welcome to decide if the code is high quality, secure and is maintained.

      • The same is just as true for modules you make yourself.

      • There’s a style of Terraform programming where people try to make everything a module. Some consider this to be an antipattern.

      • As for me, I’m glad I always tried tuning with dynamic blocks and locals to reduce my code footprint first 

      next up  “multilevel compartment deployment using this local module”

      Stay Tuned 

      No comments:

      Post a Comment