Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provider/openstack: Add fixed_ips computed attribute to port resource #12807

Closed
wants to merge 1 commit into from

Conversation

jtopjian
Copy link
Contributor

This commit adds the fixed_ips attribute to the
openstack_networking_port_v2 resource. This contains all of the port's
Fixed IPs returned by the Networking v2 API.

/cc @sebastien-prudhomme

@jtopjian
Copy link
Contributor Author

I'm not 100% happy with the name fixed_ips since it's quite close to the existing fixed_ip. Marking this WIP until either I think of a better name or cannot think of one at all.

I don't want to use ip_addresses since that implies all types of IPs, such as Floating IPs.

Suggestions are appreciated! :)

@jtopjian jtopjian changed the title [WIP] provider/openstack: Add fixed_ips computed attribute to port resource provider/openstack: Add fixed_ips computed attribute to port resource Mar 17, 2017
@jtopjian
Copy link
Contributor Author

Alright, having mulled it over for a few hours, I think fixed_ips is the safest name.

ready for review.

@sebastien-prudhomme
Copy link

Really no way with the Terraform language to use the fixed_ip attributes?

@jtopjian
Copy link
Contributor Author

@sebastien-prudhomme Not to my knowledge. Because users can specify a Fixed IP in any order and because Neutron will return those IPs in a different order, ordered lists can't be used. The "hash" form is the only way I know of.

This proposed feature will resume the previous method you were using, you would just need to add an "s" to the lines you were using it. :)

This commit adds the `fixed_ips` attribute to the
openstack_networking_port_v2 resource. This contains all of the port's
Fixed IPs returned by the Networking v2 API.
@jtopjian
Copy link
Contributor Author

I've been testing this with a bunch of scenarios and the change to TypeSet has also "broken" cases where someone specifies a fixed_ip with no ip_address (meaning, they want DHCP to issue an address). A crash does not happen, but there will be a state change upon refresh.

It seems like there's a conflict satisfying all port/IP scenarios:

  • With TypeList, when a user specifies fixed_ips out of alphabetical/numerical order, they will see a state change upon refresh.
  • With TypeSet, when a user specifies a single fixed_ip (which is probably the vast majority of users), they cannot easily reference the IP address of that IP, whether static or DHCP.
  • With TypeSet, when a user specifies a fixed_ip with no ip_address, they will see a state change upon refresh.
  • With TypeSet, there's no way, at the moment, to specify multiple fixed_ips with DHCP, since the hashing won't be able to accurately identify the fixed_ip upon first apply.

It looks like TypeSet has the bulk of the problems, but really, all but the first are edge cases. However, they still need to be accounted for.

Back to the drawing board on this one...

@jtopjian
Copy link
Contributor Author

I've created issue #13052 to better track this. I'm going to close this PR.

@ghost
Copy link

ghost commented Apr 15, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants