Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: removing Conflict Configuration Error when conflicted variable is set to null #611

Closed
lotusnoir opened this issue Jan 10, 2024 · 1 comment · Fixed by #613
Assignees
Labels
bug Something isn't working
Milestone

Comments

@lotusnoir
Copy link

lotusnoir commented Jan 10, 2024

Hello, im writting a module to use this provider
I have an issue with the variables that cannot be set together

exemple for junos_interface_physical ressource

│ Error: Conflict Configuration Error
│ 
│   with module.fwv-ang49-12.junos_interface_physical.this,
│   on ../../modules/terraform-module-srx_config/interfaces.tf line 2, in resource "junos_interface_physical" "this":
│    2: resource "junos_interface_physical" "this" {
│ 
│ only one of ether_opts, gigether_opts or parent_ether_opts block can be specified

I've declared in my ressource

resource "junos_interface_physical" "this" {
  for_each = var.interfaces_physical
  name     = each.key

  no_disable_on_destroy = each.value.no_disable_on_destroy
  description           = each.value.description
  disable               = each.value.disable
  encapsulation         = each.value.encapsulation

  dynamic "ether_opts" {
    for_each = each.value.ether_opts != null && each.value.parent_ether_opts == null ? [each.value.ether_opts] : []
    iterator = ether
    content {
      ae_8023ad        = ether.value.ae_8023ad
      auto_negotiation = ether.value.auto_negotiation
      #no_auto_negotiation= ether.value.no_auto_negotiation
    }
 }

  dynamic "parent_ether_opts" {
     for_each = each.value.parent_ether_opts != null && each.value.ether_opts == null ? [each.value.parent_ether_opts] : []                              
      iterator = popts
  
      content {
        flow_control = popts.value.flow_control
        #no_flow_control = popts.value.no_flow_control
    }     
 }
}

and on the variables

variable "interfaces_physical" {
  type = map(object({
    no_disable_on_destroy = optional(bool)
    description           = optional(string)
    disable               = optional(bool)
    encapsulation         = optional(string)
    ether_opts = optional(object({
      ae_8023ad           = optional(string)
      auto_negotiation    = optional(bool)
      no_auto_negotiation = optional(bool)
      flow_control        = optional(bool)
      no_flow_control     = optional(bool)
      loopback            = optional(bool)
      no_loopback         = optional(bool)
      redundant_parent    = optional(string)
    }))
    parent_ether_opts = optional(object({
      flow_control    = optional(bool)
      no_flow_control = optional(bool)
  }))
  default = {}
}

Do you see a way to bypass this error ? do you think you should update your code in order to accept this blocks together if they are equals to null ?
I also have to same question for all the opposite vars loopback/no_loopback, flow/no_flow etc...
Thanks in advance

@lotusnoir lotusnoir added the enhancement New feature or request label Jan 10, 2024
@jeremmfr
Copy link
Owner

Hi 👋

Thank you for raising this issue.
After testing your example, I discovered that the received resource config by the resource config validator can have unknown value for all configured attributes in modules whatever the module variable value and the final value for resources attributes/blocks. With a difference for single block, in this case block is set to known with all configured block attributes in modules to unknown value.
Unfortunately, in resource validator, I not considered this potential case and I will have to add a skip on conflict check when have :

  • a attribute with unknown value (value could be null after the config validator call)
  • a single block with null or unknown values in all block attributes (which means that the block could be null after the config validator call)

I take care of fix this and other potential same cases on other resources.

@jeremmfr jeremmfr added bug Something isn't working and removed enhancement New feature or request labels Jan 12, 2024
@jeremmfr jeremmfr added this to the v2.5.0 milestone Jan 12, 2024
@jeremmfr jeremmfr self-assigned this Jan 12, 2024
jeremmfr added a commit that referenced this issue Jan 19, 2024
avoid trigger the conflict errors when Terraform call
resource config validate and value for potential conflict
is unknown (can be null afterwards)
Fix #611
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants