Feature Request: Ability to allocate next available network container from a parent network container

[cata008]

Hi guys,

I am trying to use the IPAM functionality provided by Infoblox and integrate it with Azure, but I stumbled upon a roadblock.

To be more specific, I am trying to deploy a VNET in Azure and for that I need an address space and a subnet.

Example:

• The "global" network container used in Infoblox is, '10.122.0.0/16'.
• Azure VNET / Infoblox network container - 10.122.0.0/21, carved from the global network
• Azure subnet / Infoblox network - 10.122.0.0/24, carved from the Azure VNET

What I am looking for is to dynamically get the next available network container from '10.122.0.0/16'.

I initially tried it by creating 10.122.0.0/21 as a network and then 10.122.0.0/24 inside it, but obviously I got the error below since the tool is expecting 10.122.0.0/21 to be a network container instead. Error: Allocation of network block within network container '10.122.0.0/21' under network view 'default' failed: not found

In Infoblox Grid Manager, I can manually add 10.122.0.0/24 inside 10.122.0.0/21, and then 10.122.0.0/21 becomes a network container. How can I achieve the same using Terraform?

Provider used - infobloxopen/infoblox, version 2.0.1.

Cheers!

[cata008]

Please disregard my last question. The idea would again be to dynamically get the next available network container from a certain network (e.g. '10.122.0.0/16'). Which, I would assume it is something not supported for the time being. Any plans to implement this in a future release?

Having the same behavior from Inboblox Grid Manager into Terraform would cause issues with the tfstate file the 2nd time it is being run. Since, the original network would become a network container. Not to mention the fact that the change would strip off the network from things like dhcp reservations etc.

[somashekhar]

Hi @CatalinStreang,

Having the same behavior from Inboblox Grid Manager into Terraform would cause issues with the tfstate file the 2nd time it is being run. Since, the original network would become a network container. Not to mention the fact that the change would strip off the network from things like dhcp reservations etc.

Due to this we could not support the auto conversion of network to network container behaviour.

With this discussion, can we take the ask here is to: Support plugin to auto allocated a child network container from a parent network container

[cata008]

Hi @somashekhar, Yes, that is correct. I believe that is not on the roadmap for now, right?

[somashekhar]

@CatalinStreang as of now it was not a direct requirement from users. This will be taken as a new requirement.

[cata008]

Hi @somashekhar. Any idea when this enhancement is gonna be implemented?

[Eric-Jckson]

Hey @somashekhar and @cata008,

I have provided a PR to the infoblox go client that should add the ability to allocate the next network container. Please let me know if any changes need to be made to the PR. Thanks!

https://github.com/infobloxopen/infoblox-go-client/pull/152

[zpalight]

Hi @Eric-Jckson I saw your code that you merged regarding getting the next available network container. Do you know if your code has been implemented into a terraform function yet. I don't see any terraform function calls right now on the main page which lets me find the next available container.

[Karthik-13]

Hi @somashekhar @Eric-Jckson , any idea when this feature will be available?

[LoganRossUS]

Any idea when this enhancement will be available? The networks can be created dynamically but not the network containers.

[p2k3m]

https://registry.terraform.io/providers/pushkarmishrain/ipam/latest/docs

[nathaniel-mills]

Any news on this please?

[365ejk]

This is RFE-12916 and just created recently. Infoblox will not release this feature near time soon unless there are needs for it. If you see this message you should contact your account manager and ask to expedite it ASAP. Another solution seems to be using REST API terraform provider by mastercard or use local file execution (python or anything) but it would not give result back as a variable.

[365ejk]

Good news ! - Infoblox IPAM Driver for Terraform v2.4.x would be the solution.

[troydieter]

Good news ! - Infoblox IPAM Driver for Terraform v2.4.x would be the solution.

Hi @365ejk - has release 2.4.1 addressed this?

It still looks like the necessary data source (infoblox_ipv4_network_container) still requires the cidr parameter to be provided, which (in theory) would be used to establish the source of data for the next network.

In our use-case, the order of operation would be:

1) Utilize the infoblox_ipv4_network_container data source to look up the next available network, based on extensible attributes (ext_attrs). For example:

data "infoblox_ipv4_network_container" "supernet" {
  network_view = "default"
  cidr = var.next_net_cidr
  ext_attrs = jsonencode({
    "Zone"        = each.key
    "Region"      = var.region
    "Environment" = var.environment
  })
}

2) Utilize the infoblox_ipv4_network resource to provision, based on the returned "next network":

resource "infoblox_ipv4_network" "net3" {
  parent_cidr = infoblox_ipv4_network_container.supernet.cidr // reference to the above resource
  allocate_prefix_len = var.new_cidr
  network_view = "default" // we may omit this but it is not a mistake to specify explicitly
  comment = "even smaller network for testing"
  ext_attrs = jsonencode({
    "Site" = "any place you wish ..."
  })
}

In theory, his would look up the next available network (container), and reserve the next space available (defined as var.new_cidr) and remark it with the ext_attrs shown above. Can you advise?

[hemanthKa677]

Hi @troydieter , The latest version 2.4.1 do supports allocate next available network container in resources. To create a network container dynamically there are parameters parent_cidr and allocation_prefix_len in network container(IPV4/V6). Please have a look in documentation under docs folder for examples on next available network container.

[troydieter]

Hi @troydieter , The latest version 2.4.1 do supports allocate next available network container in resources. To create a network container dynamically there are parameters parent_cidr and allocation_prefix_len in network container(IPV4/V6). Please have a look in documentation under docs folder for examples on next available network container.

Hi @hemanthKa677 - I understand that allocation_prefix_len does fix a portion of this problem, however cidr is still required as an argument in the data.infoblox_ipv4_network.nearby_network data block. We need to be able to pull the cidr initially using only ext_attrs argument. Is this possible? Based on the documentation, I do not believe so with 2.4.1.

data "infoblox_ipv4_network" "nearby_network" {
  for_each = local.az
  network_view = "default"
  ext_attrs = jsonencode({
    "Zone"        = each.key
    "Region"      = var.region
    "Environment" = var.environment
  })
  // cidr = "192.168.128.0/20"
}

resource "infoblox_ipv4_network_container" "nc3" {
  for_each = local.az
  # parent_cidr         = "10.128.0.0/18"
  parent_cidr = data.infoblox_ipv4_network.nearby_network.cidr
  # The above block still needs to dynamically fetch the next supernet
  allocate_prefix_len = var.ip_cidr_blocks[var.tshirt_size]
  # network_view = "nondefault_netview"
  # comment = "one of our clients"
  ext_attrs = jsonencode({
    "Zone"        = each.key
    "Region"      = var.region
    "Environment" = var.environment
  })
}

Resulting in:

╷ │ Error: Missing required argument │ │ on next_available_net.tf line 9, in data "infoblox_ipv4_network" "nearby_network": │ 9: data "infoblox_ipv4_network" "nearby_network" { │ │ The argument "cidr" is required, but no definition was found. ╵