Skip to content

[FEATURE] Network Policy vs Network Policies #518

Description

@kcbimonte

What area do you want to see improved?

terraform provider

Is your feature request related to a problem? Please describe.

Not necessarily a problem, but the current network policy resource feels cumbersome due to it allowing multiple rules to be contained in one block much like the legacy aws security group resource.

This requires scanning of resource block content to find the one rule block when needing to update the rule content.

Describe the solution you would like

Take a small page out of the AWS Provider and instead do something like the following:

resource "cloudfoundry_network_policy" "app_1_app_2_http" {
  app_id = data.cloudfoundry_app.app_1.id

  target_app_id  = data.cloudfoundry_app.app_2.id
  from_port      = 80
  to_port        = 80
  ip_protocol    = "tcp"

  policies = []  # deprecated but kept for compatibility and to be removed in a future version
}

resource "cloudfoundry_network_policy" "app_1_app_2_range" {
  app_id = data.cloudfoundry_app.app_1.id

  target_app_id  = data.cloudfoundry_app.app_2.id
  from_port      = 8090
  to_port        = 8092
  ip_protocol    = "udp"
}

# Same resource behavior as current policy block
resource "cloudfoundry_network_policies" "policies" {
  policies = [
    {
      source_app      = "16b53647-9709-44bf-91b2-116de83ffd3d"
      destination_app = "41048361-adc7-4686-9115-36b16d8df12c"
      port            = "61443"
      protocol        = "tcp"
    },
    {
      source_app      = "16b53647-9709-44bf-91b2-116de83ffd3d"
      destination_app = "41048361-adc7-4686-9115-36b16d8df12c"
      port            = "8090-8092"
      protocol        = "udp"
    }
  ]
}

This approach would create a non-breaking change and allow people to switch over to either the policies resource or individual resources. It also more accurately reflects the naming of the resource by scoping policy down to one policy instead of n policies.

With Terraform / OpenTofu having a move block, migration from policy to policies should be straightforward. The only caveat to that is if the from and to port pattern is also incorporated into the policies resource.

Describe alternatives you have considered

Just using the existing functionality and having one entry per a resource list

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions