THREE problems in resource "fortios_router_multicast"

[krzysztofmaciejewskiit]

1. The first problem is that when adding, it randomly threw me errors that the value for a parameter was missing (you can see in the picture what parameters were involved).
   

2. The second problem is that when I delete a given entry it disables the “Multicast Routing” option, even though the resource that is responsible for enabling it (named pim-on-gre) is not deleted.
   
   

3. The third problem with this resource is that when I add a second entry it overwrites the first one. Of course, it has a different name and a different resource name.
   
   

I believe that these three prblems are interrelated.

[MaxxLiu22]

Hi @krzysztofmaciejewskiit ,

Thank you so much for raising these important questions and for your continued support of our community. Regarding your inquiries:

1: Typically, GUI and Terraform both use API to send request, the FOS backend fills these undefined arguments with default values . However, in this instance, the resource failed. The GUI is handling these undefined arguments on the API side during requests. I'll consult with the relevant team to determine if this behavior is intentional and if Terraform need to handle this.

2: I wasn’t able to replicate the issue when deleting an interface block from a single fortios_router_multicast resource. However, I did notice that you might have multiple fortios_router_multicast resources. On FGT, fortios_router_multicast is a static table on FGT that can only be edited and retrieved. If there are multiple fortios_router_multicast resources with conflicting configurations, the last one executed will overwrite the previous ones, which could be the cause of the issue you're experiencing.

3: According to the FNDN API documentation, individual interfaces currently cannot be managed through a dedicated resource. They can only be edited and retrieved as part of the fortios_router_multicast block. Terraform ensures that the interface configuration on the FGT aligns exactly with your Terraform configuration. I'll reach out to the API team to explore the possibility of introducing an independent API to manage interfaces separately.

If these steps don’t resolve your questions, could you kindly provide your FOS version, Terraform FOS version, and the related resources you're working with? This will help us assist you more effectively.

Thanks,
Maxx

[krzysztofmaciejewskiit]

Terraform version: v1.8.5
FortiOS version: v7.2.4

1. thanks, it would be nice if Terraform itself would insert default values there as it does with other parameters.

2. my code in its entirety looks like this:
   
   
   And when I delete I do so:
   
   
   In my opinion, then the entry should be removed, but "Multicast Routing" itself should be enabled, because I only remove the part responsible for the entry.

3. Do you mean I can't add two different entries using Terraform because one will overwrite the other (that's what's happening with me now)?

[MaxxLiu22]

Hi @krzysztofmaciejewskiit,

Thank you for the information.

Regarding question 2:

At present, the fortios_router_multicast resource functions differently from fortios_router_ospf, where blocks can be managed by individual resources. Unlike fortios_router_ospf, where neighbors can be managed through a separate resource (fortios_routerospf_neighbor), in fortios_router_multicast, all arguments and blocks, including interfaces, are managed within the same resource.

Therefore, it is recommended to have only one fortios_router_multicast resource. If you use multiple fortios_router_multicast resources, please ensure they do not manage the same arguments to avoid conflicts

If you comment out the entire fortios_router_multicast resource, Terraform will remove all associated settings, including multicast_routing, which will disable multicast routing. However, if you only intend to remove a specific interface, it's recommended to comment out just the interface block, as shown below:

resource "fortios_router_multicast" "pim-on-gre-tunnel" {
  depends_on = [fortios_router_multicast.trname]

  # interface {
  #   bfd        = "enable"
  #   name       = "port2"
  #   pim_mode   = "sparse-mode"

  #   igmp {
  #     version                     = "2"
  #     query_interval              = 20 # added due to an error (null) during configuration
  #     query_timeout               = 60 # added due to an error (null) during configuration
  #     query_max_response_time     = 15 # added due to an error (null) during configuration
  #     last_member_query_interval  = 1  # added due to an error (null) during configuration
  #     last_member_query_count     = 2  # added due to an error (null) during configuration
  #   }
  # }

  interface {
    bfd        = "enable"
    name       = "port3"
    pim_mode   = "sparse-mode"

    igmp {
      version                     = "2"
      query_interval              = 20 # in additional, because it was throwing an error (null) during addition
      query_timeout               = 60 # in additional, because it was throwing an error (null) during addition
      query_max_response_time     = 15 # in additional, because it was throwing an error (null) during addition
      last_member_query_interval  = 1  # in additional, because it was throwing an error (null) during addition
      last_member_query_count     = 2  # in additional, because it was throwing an error (null) during addition
    }
  }
}

Regarding question 3:

As mentioned earlier, the interface block is a list of map elements under the fortios_router_multicast resource. This means that multiple instances of fortios_router_multicast will overwrite one another, it is better to manage all interfaces under one fortios_router_multicast resource. However, if you believe it would be more suitable to manage the interface blocks as individual resources, I will reach out to the API team to inquire whether it would be possible to separate the interface into an individual API. This way, Terraform could develop a fortios_router_multicast_interface resource to manage each interface independently.

Thanks,
Maxx

[krzysztofmaciejewskiit]

I will refer to the whole resource.

I can't comment on a certain part of the code (or remove part of the code) due to the specifics of my project, to remove something they had to remove the entire resource.

I think it will be better to manage this individually because it will be more logical in my opinion, and it will make someone who writes such code more flexible, because I want to run "Multicast Routing" permanently and gradually add entries to the board (in other blocks so that when removing an entry does not disable Multicast Routing) and I always have to do to a new resource.

Please also respond to the second problem I reported (#344). Thanks

[MaxxLiu22]

Hi @krzysztofmaciejewskiit ,

Thank you for your suggestion. I have submitted an internal feature request, including your requirements, to the API team to explore the possibility of separating the interface block as an individual API in our product.

[krzysztofmaciejewskiit]

Thanks. How long can it take to process such a “request” + implement it?

[MaxxLiu22]

Hi @krzysztofmaciejewskiit,

I’ve submitted the request to the API team, and they are currently reviewing it along with this GitHub case. Processing time may take a few weeks, depending on the team’s workload. I’ll continue to monitor the ticket’s progress closely and will keep you updated as soon as there’s any news.

Thanks,
Maxx