Change port mac will cause instance destroy and recreate

Terraform Version

1.53.0

Affected Resource(s)

openstack_compute_instance_v2
openstack_networking_port_v2

Expected Behavior

Port just changed mac and instance will still use the port.

Actual Behavior

Port recreate with new mac and instance destroy and recreate.

@suddenDisappear

@suddenDisappear thanks for the bug report. could you please provide more details? TF snippets, API debug logs?

@suddenDisappear thanks for the bug report. could you please provide more details? TF snippets, API debug logs?

My tf demo is like below:

terraform {
  required_providers {
    openstack = {
      source  = "hashicorp/openstack"
      version = "1.53.0"
    }
  }
  required_version = ">= 1.5.7"
}

provider "openstack" {
  region                            = "RegionOne"
  auth_url                          = "http://xxx.xxx.xxx.xxx:5000/v3"
  user_domain_name                  = "Default"
  domain_name                       = "Default"
  tenant_name = "admin"
  user_name   = "xxx"
  password   = "yyy"
}


resource "openstack_networking_port_v2" "port" {
  network_id               = "d67c588a-9613-4319-8bad-e11fb55cc112"
  admin_state_up           = "true"
  mac_address              = "fa:16:3e:c8:0c:03"
}

resource "openstack_compute_instance_v2" "vm" {
  block_device {
    uuid                  = "a8ee404f-8474-403b-95b4-41f13c4e0aec"
    source_type           = "image"
    boot_index                 = 0
    destination_type           = "volume"
    delete_on_termination      = true
    volume_size = 40
  }
  availability_zone   = "nova"
  name                       = "test"

  network {
    port = openstack_networking_port_v2.port.id
  }

  flavor_id        = "c1.medium"
  metadata = {
    admin_pass               = "test@123"
  }
}

If I change the mac from fa:16:3e:c8:0c:03 to fa:16:3e:c8:0c:04,the terraform destroy plan will show port must replace and cascade cause instance destroy and recreate.

As openstack api describe, change mac_address not cause port destroyed,so maybe it's not necessary to destroy port but update port mac_address instead.

openstack ports update

@suddenDisappear

@suddenDisappear thanks for the details. MAC address update must be implemented in gophercloud first. Can you proceed with this?

@kayrus

hey @kayrus, can we bump gophercloud's version to 2.10.0 so we can have the necessary change for updating MAC addresses?

sure. just submit a PR

Here it is #2004.

@kayrus

@kayrus I never developed for a terraform provider, so I have a question...

Apparently, we can't change the MAC address while a port is attached to a server (which seems ok). But, by design, I believe it won't make sense to dettach from a server and attach it again after the update. Still, do we want to support the ability to update mac addresses for ports?

but got 409 instead: {"NeutronError": {"type": "PortBound", "message": "Unable to complete operation on port 4988c401-c52c-4c99-af2b-830cc0d0e517, port is already bound, port type: ovs, old_mac fa:16:3e:c8:0c:04, new_mac fa:16:3e:c8:0c:05.", "detail": ""}}

well, you can add support for the port MAC address update, but in port resource docs you should mention that the port must be detached before the mac update.
from the other hand, it's more straightforward to keep this as is, when terraform automatically resolves the dependencies and detaches the port before update the MAC.

do you have other thoughts?

well, you can add support for the port MAC address update, but in port resource docs you should mention that the port must be detached before the mac update.

That is a option, but I think it's weird the user detach the port manually and after that run the terraform, or run one apply to remove port and update it and run another one to attach it again.

do you have other thoughts?

I was taking a look how other providers do, and I found this for the AWS provider. It has a interface_attachment resource that manages attachment and terraform controls the dependency between server <-> port

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#network-interfaces

Maybe add a new resource just to manage this kind of use case is like using a sledgehammer to crack a nut. What do you think?

That is a option, but I think it's weird the user detach the port manually and after that run the terraform, or run one apply to remove port and update it and run another one to attach it again.

actually this should happen automatically in one run, same way AWS provider does this, see https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/resources/compute_interface_attach_v2#attachment-using-an-existing-port

Navigation Menu

Repository navigation

Change port mac will cause instance destroy and recreate #1942

Terraform Version

Affected Resource(s)

Expected Behavior

Actual Behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Change port mac will cause instance destroy and recreate #1942

Description

Terraform Version

Affected Resource(s)

Expected Behavior

Actual Behavior

Activity

kayrus commented on Aug 1, 2025

suddenDisappear commented on Aug 27, 2025

kayrus commented on Aug 28, 2025

winiciusallan commented on Jan 6, 2026

kayrus commented on Jan 7, 2026

winiciusallan commented on Jan 7, 2026

winiciusallan commented on Jan 12, 2026

kayrus commented on Jan 15, 2026

winiciusallan commented on Jan 16, 2026

kayrus commented on Jan 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions