coverage: 78.733%. remained the same
when pulling f4c6a8e on kayrus:secgroup-stateful-v2
into e36df0f on gophercloud:v2.

This requires the stateful-security-group extension. Do we want to document this in the help text? On a lesser note, do we want to check for the extension first in the functional test, or do we assume OVS/OVN?

@stephenfin looks like the initial PR was incorrect, and I had to put this option into the openstack/networking/v2/extensions. So what's the plan? Fix the master branch, then update v1 and v2 backports?

Hm, looking at the allowed_address_pairs for ports. It's also an extension, but it resides in the openstack/networking/v2/ports.

Hm, looking at the allowed_address_pairs for ports. It's also an extension, but it resides in the openstack/networking/v2/ports.

Yeah, I suspect there are quite a few cases of this: the beauties of having extensions that can change absolutely anything about the API 😅 At least CreateOpts.stateful is a pointer so someone can omit it entirely during creation if the networking backend doesn't support it. That's not the case for the result struct though 😞

Perhaps we could just document that it relies on the extension and will be unset if that extension is absent? afaict it will always be present on the OVN, OVS and linuxbridge backends, but that's not necessarily true for other backends.

I also missed the fact that this was a backport, so feel free to ignore my comments entirely here. It would be good to fix this on master though, IMO.

v1 backport was already approved, can we merge this so we can close this topic until v3?

@stephenfin thanks. I added comments about the stateful flag in TF provider docs: https://github.com/terraform-provider-openstack/terraform-provider-openstack/blob/fa1184eb117d93b42b24bfc2019e62b1689f214e/docs/resources/networking_secgroup_v2.md