The problem with default Security List and Default Route Table :

• they are created by default with every VCN and cannot be deleted
• they are assigned to your subnet if you don’t specify one at creation creation time

That may lead to unexpected behavior and should be avoided past the "quick demo vcn" step.

This is a "sane defaults" design proposition for this module:

• empty Default Security List,
• guide user to create a dedicated SL/RT per subnet

That way, if someone create a subnet without specifying SL, it is just unreachable 🤷‍♂️

Ideally, this should be a feature like "enable/disable Default Security List Lockdown" so the module user still keeps control and flexibility over how his vcn is configured.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

VCN module currently supports creating each available gateways, except for Local Peering Gateways (referred as LPG now on).

The proposition is to give the user an option to create one or many LPG within the same VCN block definition, with the following options:

• declare its peer_id or not,
• attach a Route Table to the LPG or not, by setting route_table_id

Adding one or many LPG to a VCN should be kept optional.

These options will enable higher level constructs, like hub-and-spoke network topology. But it is important to keep VCN module agnostic to such specific configuration:

• based on the arguments passed by the user to the VCN module, the resulting VCN should be able to act either as a HUB or a SPOKE,
• when composing with many VCN modules, the user should be able to create a complete hub-and-spoke topology.

New or Affected Resource(s)

• oci_core_vcn will need new Input Variables
• new resource oci_core_local_peering_gateway, implemented with a for_each logic to handle many of them,
• possibly new oci_route_table to handle HUB scenario (preferably via a sub-module for route tables)

Potential Terraform Configuration

Below a mock-up of how the user would declare new LPGs

module "vcn" {
  source = "../"

  # general oci parameters
  compartment_id = var.compartment_id
  label_prefix   = var.label_prefix
  tags           = var.tags

  # vcn parameters
  create_drg               = var.create_drg               # boolean: true or false
  internet_gateway_enabled = var.internet_gateway_enabled # boolean: true or false
  lockdown_default_seclist = var.lockdown_default_seclist # boolean: true or false
  nat_gateway_enabled      = var.nat_gateway_enabled      # boolean: true or false
  service_gateway_enabled  = var.service_gateway_enabled  # boolean: true or false
  vcn_cidr                 = var.vcn_cidr                 # VCN CIDR
  vcn_dns_label            = var.vcn_dns_label
  vcn_name                 = var.vcn_name

  # gateways parameters
  drg_display_name = var.drg_display_name

  local_peering_gateways = {
    to_spoke1 = {
      peer_id = <string>
      route_table_id = <string>
    },
    to_spoke2 = {
      peer_id = <string>
      route_table_id = <string>
    },
  }
}

References

Examples using specific versions from the Terraform Registry of a submodule are often not aligned with the current main branch leading to error and unexpected behavior.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

New or Affected Resource(s)

The route rules are defined like this:
variable "internet_gateway_route_rules" {
description = "(Updatable) List of routing rules to add to Internet Gateway Route Table"
type = list(object({
destination = string
destination_type = string
network_entity_id = string
description = string
}))
default = null
}

Since all of them are of type string, can change the type to a simple list of string?

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Current quickstart documentation is not so quick. New module users would benefit from a shorter quickstart document, even if it implies to take some opinionated choices.

The point is to have a vcn provisioned with the least possible steps to encourage newcomers to give it a try.

New or Affected Resource(s)

Potential Terraform Configuration

• Focus on clone from Terraform registry use case and remove the clone from git section from quickstart.
• maybe a single file config, or instructing to copy the content of files from an example

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Add a switch to enable or disable IPv6 on a managed VCN.

New or Affected Resource(s)

oci_core_vcn.is_ipv6enabled

Potential Terraform Configuration

module "vcn" {
...
enable_ipv6 = var.enable_ipv6
...
}

variable "enable_ipv6" {
description = "Whether IPv6 is enabled for the VCN. If enabled, Oracle will assign the VCN a IPv6 /56 CIDR block."
type = bool
default = false
}

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Add an easy way for VCN module user to enable VCN logging on subnets.

New or Affected Resource(s)

tbd

Potential Terraform Configuration

Possibly using oci-logging module when it is published on Terraform Registry.

References

Last CHANGELOG entrie is from version 1.0.3. Need to update it with v2.0.0 changes.

The module offers currently two choices to name the gateways, but neither is fully customizable:

• prefix+fixed_value
• fixed_value

For example, an internet gateway will be named either internet-gateway or terraform-oci-internet-gateway with prefix set to "terraform-oci" (default value).

This is a feature request to add custom name support for gateways (igw, ngw, sgw, drg) directly from module inputs.
Ideally, these inputs should be optional, with sane defaults.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The DRG Attachment is now visible in the OCI console. Currently, we do not set it so it gets named like "drgattachment20210601034821". Can we please put some formatting so the attachment is neatly named?

New or Affected Resource(s)

oci_core_drg_attachment.drg

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

hi all
when we tried to create an vcn with service gateway gaves these error code

module "vcn" {
source = "oracle-terraform-modules/vcn/oci"
version = "2.0.0"

insert the 4 required variables here

compartment_id = oci_identity_compartment.Develop.id
region = var.prov_RegionEU
vcn_dns_label = "demo"
vcn_name = "VCN01DEMO"
internet_gateway_enabled = true
service_gateway_enabled = true
vcn_cidr = "10.12.0.0/16"
}

Error: 400-InvalidParameter
Service: CoreServiceGateway
Error Message: The maximum limit of 0 for Service gateway per VCN has been exceeded in VCN ocid1.vcn.oc1.eu-frankfurt-1.

OPC request ID: 3599a3442aebd13668ddf39e884c54d7/5503E0D275D2D4821CDEAAB270319154/9F3865B6EDFBAB160991940BC998B699
Suggestion: Please update the parameter(s) in the Terraform config as per error message: The maximum limit of 0 for Service gateway per VCN has been exceeded in VCN ocid1.vcn.oc1.eu-frankfurt-

if i does not specify the service gateway all works well

module "vcn" {
source = "oracle-terraform-modules/vcn/oci"
version = "2.0.0"

insert the 4 required variables here

compartment_id = oci_identity_compartment.Develop.id
region = var.prov_RegionEU
vcn_dns_label = "demo"
vcn_name = "VCN01DEMO"
internet_gateway_enabled = true
vcn_cidr = "10.12.0.0/16"
}

created ok
if i creted and later canged to add the service gateway , it gaves us the same error

thanks

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The goal is to give an easy way to test the module examples, adding "Deploy to Oracle Cloud" button

• Examples currently guides the user toward a cli centric deployment workflow, which requires some prerequisites.
• Adding a new way to deploy the example, using OCI Resource Manager and the "Deploy to Oracle Cloud" would give a simpler option.

New or Affected Resource(s)

• Examples documentation in /examples folder
• GitHub releases, which will need to contain the zip file that will be targeted by the "Deploy to Oracle Cloud" button

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

Using the Deploy to Oracle Cloud Button

Add a validation condition so the display name in the terraform.tfvars file is not an empty string: https://www.terraform.io/docs/language/values/variables.html#custom-validation-rules

Originally posted by @hyder in #55 (comment)

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

oci_core_drg_attachment got new capabilities related to the recent DRG enhancements.

A DRG can now be attached to multiple VCN.
vcn_id argument is now deprecated and should be replaced by network_details

network_details {
        #Required
        id = var.drg_attachment_network_details_id
        type = var.drg_attachment_network_details_type

        #Optional
        route_table_id = oci_core_route_table.test_route_table.id
    }

New or Affected Resource(s)

oci_core_drg
oci_core_drg_attachment.drg

Potential Terraform Configuration

With the new DRG enhancements, there is also a lot more option to attach route tables, at different levels. This will need a detailed review and planning.

It may be the point when we split drg code to his own sub-module.

References

PR #45
Issue #44

In production it is often useful to have a stable IP address for the NAT in a VCN across rebuilds of the VCN. Sometimes a customer will have opened their firewall for a specific IP, so it is important to maintain that same IP over time even as the underlying infrastructure is rebuilt.

resource "oci_core_public_ip" "nat_public_ip" {
  compartment_id = var.compartment_id
  lifetime       = "RESERVED"
  display_name   = "IP Address for NAT"
}

For this project, it would be enough to just have a property that I can feed the reserved IP address into. My base terraform script will create the reserved IP and then invoke this one, passing the IP.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version and Provider Version

Affected Resource(s)

Terraform Configuration Files

The variable definition is like the following:

variable "local_peering_gateways" {
  description = "List of Local Peering Gateways to attach to the VCN."
  type        = map(any)
  default     = null
}

The variable is a map but the description says list. Please correct the description.

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. 
# Please remove any sensitive information from configuration files before sharing them. 

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

1. terraform apply

Important Factoids

References

https://docs.cloud.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/terraformconfigresourcemanager.htm

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Since 2.x releases, we've set a minimum version of 0.13. However, due to dependencies, downstream modules (oke, base) need an updated version in order to fix oracle-terraform-modules/terraform-oci-oke#290

New or Affected Resource(s)

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

Wrong CIDR for class B network in RFC1918. Need to check and update other examples as well.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

When DRG is created using the submodules (create_drg=false) and routing rules with the special string "drg" are used, it fails.
This happens because when the special string "drg" is used the module expects to find a DRG created internally (deprecated).

The attached DRG should be provided as input to the module.

Affected Resource(s)

Route tables

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file.
# Please remove any sensitive information from configuration files before sharing them.

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

1. terraform apply

Important Factoids

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Issue #14 added support for using a reserved IP created outside of this module by refering the resource's OCID.
But provisioning of this reserved IP is currently not handled by the module.

This issue propose to resolve this by adding a new feature that would:

• provision a new Reserved IP
• Associate the Reserved IP with the NAT gateway created by the module.

This feature should preserve the possibility for the user to reuse an existing Reserved IP.

New or Affected Resource(s)

To be evaluated.

Potential Terraform Configuration

# Nothing yet. 

References

The more I think about pinning version in modules examples or not, the more I tend to say no. Here is the rational behind my current view on that matter.

The problem is that the example's files are not released yet, hence version 3.2.0 will not be able to support this example: user will get an error when trying to copy/paste and execute the example.

In addition, we would always need to come back to example files and keep module version current.

Letting modules in examples without versions on purpose seems to be a better tradeoff:

• less maintenance,
• released versions on the registry (that is, with a tag) always works.
• bleeding edge users can always source the module using the git pattern url and use repo's HEAD (great for testing by the way).

But let's settle this later and not block the PR from being merged into main. If we choose to not pin module versions in examples, we will to search and update every occurrences of it before cutting the next release tag.

Originally posted by @kral2 in #72 (comment)

When label_prefix is not given, a hyphen is added to the resource name. Please correct .

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Add ability to create a Remote Peering Connection (RPC) with another VCN. Best if we can add it in a submodule inside VCN instead of top-level.

New or Affected Resource(s)

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used.

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Affected Resource(s)

Quickstart.doc and any other AsciiDoc document in this repo that use include:: is not rendered properly.

This is initially used to include code snippets without having to duplicate information, but GitHub security parameters prevent it. This is a known limitation of AsciiDoc when used on GitHub: github/markup#1095

Proposed fix

as the includes in the quickstart is mainly used for complete doc inclusion, we should replace the include:: with a link to the file in the repository.

When adding connectivity to on-premise networks, we need to to use a DRG.

Error: did not find a proper configuration for private key

on vcn.tf line 4, in resource "oci_core_vcn" "vcn":
4: resource "oci_core_vcn" "vcn" {

I have the keys placed in the corresponding ../keys/***.pem

Please assist.

terraform version: 0.13.4.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

add support for defined tags.

New or Affected Resource(s)

oci_core_vcn and any child object managed by the module.

Potential Terraform Configuration

see oci-compute-instance module's defined_tags implementation

References

module can now be used directly from the registry

Step 5 ask to clone the module using git. This module now being live in the terraform registry, we should update the README accordingly

module composition

the pattern described by "Example reusing terraform-oci-vcn and extending to create other network resources." is known as module composition. We should use this term and point to the related terraform documentation .

Some required modules for this approach are not existing or not published yet : content will need to evolve using modules as much as possible as they become available.

From PR #23 review: "If your variable is controlling a behaviour, use imperative style to name it e.g. lockdown_default_seclist"

These variables should be renamed to the suggested name to be in line with this coding convention.

• var.internet_gateway_enabled -> var.create_internet_gateway
• var.nat_gateway_enabled -> var.create_nat_gateway
• var.service_gateway_enabled -> var.create_service_gateway

It is imperative mode, but I also suggest to change the verb from enable to create.
enable and create are different verbs from the API point of view, and we should reflect it more precisely, as the current module action is "create in enabled state".

For example, it is totally possible to create a nat gateway with a disabled state.

Yet, renaming these variables is a breaking change and would need a major version bump.
Plan should be to change these variables on the next major version but start using the suggested naming here for any new variable that controls a behaviour.

The id of the created Internet Gateway resource should be returned.

When wrapping a resource behind a module, the most common problem is that you cannot interact with it as you would with the original resources, or let's say you can interact with the module inner resources as much as your Inputs and Ouputs permits.

We need output that gives access to all existing attributes: that's key for reusability with module composition and when using remote state data source.

Some examples that could be interesting on a vcn: vcn_domain_name, display_name, the default resources ids (default SL, default RT, default DHCP Options), time_created.

VCN is a fundamental module: we don't know yet what will be built with it, so the tool should allow for great level of flexibility.

Ideally, the solution should update itself as provider adds new attributes. In the long run this means lower maintenance on the module.

Originally posted by @kral2 in #32 (comment)

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Currently, the module creates two route tables (internet-route and nat-route), only if the related gateways are created by the module.

We need to be able to create and manage route tables independently from gateway provisioning. This will enable support for Transit Routing configuration and other advanced design patterns.

The initial idea is to have a route table sub-module that can be called independently or from with the VCN module block.

New or Affected Resource(s)

oci_core_route_table

Potential Terraform Configuration

Nothing yet. Module API needs to be defined.

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

#37 would benefit from this feature.

Add an optional configuration for accessing resources via the Service Gateway via the DRG (allows access via FastConnect / VPN connections).

Requires an additional Route Table for the DRG and the Service Gateway.
Service Gateway requires routes for the On-Prem CIDRs via the DRG.
DRG requires route for the Service Gateway.

Service Gateway Route Table would be added to the Service Gateway Creation.
DRG Route Table would need to be added to the DRG Attachment.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

New or Affected Resource(s)

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used. 

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Actually, var.vcn_dns_label is a required input, and there is no easy way to just disable "Internet and VCN resolver" on a VCN. DNS label also must be an alphanumeric string that begins with a letter.

We should be able to easily disable DNS if it is not wanted, and also check that module user provides a valid string before trying to apply the configuration.

New or Affected Resource(s)

oci_core_vcn

Potential Terraform Configuration

1. making dns_label optional: we need to declare a default value
2. provision a vcn with DNS disabled: set var.vcn_dns_label to null
3. check for valid string: add a validation condition on the variable that should match a regex

The variable definition below would solve (1) and (3). (2) is addressed by the module user at module block definition time.

variable "vcn_dns_label" {
  description = "A DNS label for the VCN, used in conjunction with the VNIC's hostname and subnet's DNS label to form a fully qualified domain name (FQDN) for each VNIC within this subnet"
  type        = string
  default     = "vcnmodule"

  validation {
  condition     = length(regexall("^[^0-9][a-zA-Z0-9_]+$", var.vcn_dns_label)) > 0
  error_message = "DNS label must be an alphanumeric string that begins with a letter."
  }

References

oci.core.vcn.dns_Label
terraform regexall function

Argument cidr_block is now deprecated and cidr_blocks should be preferred instead.

cidr_blocks is a new argument that brings support for Modifiable VCNs feature from November 12, 2020.

Link to provider documentation

Current module implementation relies on var.vcn_cidr with the following definiton

variable "vcn_cidr" {
  description = "cidr block of VCN"
  default     = "10.0.0.0/16"
  type        = string
}

It is then used in resource definition like this

resource "oci_core_vcn" "vcn" {
  cidr_block     = var.vcn_cidr
  compartment_id = var.compartment_id
  display_name   = var.label_prefix == "none" ? var.vcn_name : "${var.label_prefix}-${var.vcn_name}"
  dns_label      = var.vcn_dns_label

  freeform_tags = var.tags
}

Internally, we need to stop using cidr_block argument and start using cidr_blocks. But there is many ways to handle it on our module API.

I see three ways to solve that problem:

1. with incompatible API change: e.g changing the input type (from string to list(string))
2. with backward compatible API change that mimic the service API choice: adding a new input cidr_blocks and deprecate cidr_block
3. with no API change but non-explicit/standard way to declare CIDRs as a list : keeping the same input name and type, and internally parse it for a comma separator with a Terraform function

I would like to avoid (1) and offer a smooth transition for users and all downstream modules.
(3) is the most transparent way to handle it inside the module and hide the details from the user, but I am afraid of added complexity with this non-standard and non-explicit usage pattern.

That let us with (2) as the preferred option.

This change will also require good documentation and probably some input validation to handle the " usage rules" that comes with it from service API:

cidr_blocks update must be restricted to one operation at a time (either add/remove or modify one single cidr_block) or the operation will be declined.
new cidr_block to be added must be placed at the end of the list.

These two rules are the most critical/non-usual to take care of. For the other rules (valid CIDR, limits, etc), I think we can rely on the API error messages.

@hyder @slevey : what's your thoughts about this?

region is not a required argument to create a vcn but var.region have no default value, which makes it a required input.
This also relates to issue #2 which was partially fixed by PR #4

variables.tf L5

variable "region" {
  # List of regions: https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#ServiceAvailabilityAcrossRegions
  description = "the OCI region where resources will be created"
  type        = string
}

var.region should have default as null to make it optional without defining an arbitrary value.

variable "region" {
  # List of regions: https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#ServiceAvailabilityAcrossRegions
  description = "the OCI region where resources will be created"
  type        = string
  default     = null
}

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The OCI provider has moved to "oracle/oci". We need to update the required_providers.

New or Affected Resource(s)

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used.

References

Hi,

there are no references in this module to the variables api_fingerprint,
'api_private_key_path, region, tenancy_id, user_id. They all seem to be provider related. Since [providers should be passed from outside the module](https://www.terraform.io/docs/configuration/modules.html#providers-within-modules) anyway, they can be removed. In particulary, the region` does not default to anything, so I have to pass it even if it does nothing.

When adding connectivity to on premise networks, we need to be able to add configurable route rules to the relevant on-premise CIDR blocks and route it through a DRG. These route rules should be added to the NAT route table as it will be used by private subnets.

Pass the vcn id as a variable.

If vcn exists, check if internet_gateway is needed. Create if internet gw doesn't exist.
If vcn exists, check if nat_gateway is needed. Create if nat gw doesn't exist.
If vcn exists, check if service_gateway is needed. Create if service gw doesn't exist.

Change outputs accordingly.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Custom route rules feature introduced by fixing #17 in release v2.2.0 use twi new module Input Variables:

• var.internet_gateway_route_rules
• var.nat_gateway_route_rules

They are both complex structural types.

type = list(object({
  destination       = string
  destination_type  = string
  network_entity_id = string
  description       = string
}))

Advantages:

• the variable is self-documenting
• we enforce a schema that is expected by OCI API.

Drawbacks:

• it can be complex for new users,
• seems Resource Manager do not handle objects well
• all fields becomes required. Optional object type attributes is still an experimental feature from 0.14

The goal is to simplify usage of these new variables, without loosing too much on schema enforcement and documentation.

• solution 1: use type map(any)
• solution 2: use type list(map(any)) or list(map(string))
• solution 3: use type list(object) with optional attributes

Solution 3 may be a long term approach, when optional attributes will become a supported feature of Terraform. It gives both self-documented variable and simplified input with optional attributes.

With map(any), the module user would have to provide a key for each rule despite the OCI API do not require it and the accepted schema needs to be discovered by the user from documentation. That's not simplification.

Using list(map(any)) we we loose some constraint validation in comparison with list(map(string)).

I would suggest using list(map(string)) instead of the current list(object) and reevaluate this choice when Optional object type attributes becomes a supported feature.

The change can be transparent for the module users in later releases if we stay with a list type at the primary level.

Potential Terraform Configuration

variable "nat_gateway_route_rules" {
type = list(map(string))
default = [
  {
    destination = "192.168.0.0/16" # Route Rule Destination CIDR
    destination_type = "CIDR_BLOCK"
    network_entity_id = "drg"
    description = "Terraformed - User added Routing Rule"
    },
    {
      destination = "172.16.0.0/16"
      destination_type  = "CIDR_BLOCK"
      network_entity_id = module.vcn.drg_id
      description  = "Terraformed - User added Routing Rule"
    },
  ]
}

See Github documentation:

• issue templates
• Pull request templates

Exact format needs to be discussed.
terraform-provider-oci issue templates should be a good point to start with.

The repository documentation is currently a combination of Markdown and AsciiDoc.

We are in a situation where some files exists in both format and the same content requires to be updated twice.
Also contributors needs to constantly switch between between two markup languages.

While AsciiDoc allows for a more structured content, Terraform registry only supports Markdown.
I would suggest to use Markdown only.

Even if it is more limited that AsciiDoc, it is more common and would help when:

• integrating with other solutions: if we start to automate some parts of the documents, Markdown support is more easily found than AsciiDoc
• new contributors make changes: potentially less "new things" to learn before contributing

Hello
For an internal project i had to use some of the modules, the variables of many of the modules have already "default" values deep inside the variables.tf and if for some reason users they have derived code from these modules then the defaults values are used and in some conditions this can leed to errors and endless hours of debugging to understand why a value was wrong.
Removing ALL DEFAULTS VALUES will fail the terraform scrips EXPLICITLY and then the user will be able to update them to a terrafromtf.vars file this will help us to speed up with the re utilisation of the modules instead of trying to debug :(
Thanks
Eugene

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Currently, the module do not manage subnets. It is up to the user to create them, outside of this module.

The initial idea is to have a subnet sub-module that can be called independently or from with the VCN module block.

New or Affected Resource(s)

oci_core_subnet

Potential Terraform Configuration

# Copy-paste any Terraform configurations for how the requested feature may be used.

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

currently var.tag controls the freeform tags creation. We should make it more specific, so we can also support defined tags without confusion.

New or Affected Resource(s)

all resources managed by the module

Potential Terraform Configuration

var.tags--> var.freeform_tags

References