r/distributed_port_group: Use MOID as resource ID #202
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The additions that are in #201 dictate the basis for how we will be working with vSphere networks in the future - any resource that requires a network for a backing (ie: virtual ethernet cards, VMkernel nics, etc) will require a MOID to some sort of network, versus the name itself, allowing us to circumvent actually searching for the network in the downstream resource itself. Searching would be circumvented altogether in the case of DVS portgroups being managed by TF completely as we would just pass the MOID to the downstream resource. The current behaviour of the vsphere_distributed_port_group resource is to use the key attribute in the MO as the ID of the resource, which is documented in the API as the UUID of the DVS port group, although in reality it actually seems to be the MOID, which allows #201 to work without issue right now. However, in order to guarantee that things will be stable in the long run, we need to be sure we are using the right values, so this update changes the ID to be the MOID of the object itself. key is now being exported as a computed attribute of the same name.
catsby
reviewed
Oct 12, 2017
| pgID := d.Id() | ||
| pg, err := dvPortgroupFromUUID(client, dvsID, pgID) | ||
| pg, err := dvPortgroupFromMOID(client, pgID) |
There was a problem hiding this comment.
The method signature of dvPortgroupFromMOID changes here, but I don't see that in the changes here. Was it changed elsewhere, and this resource currently doesn't work without this change?
There was a problem hiding this comment.
Not just the signature, but the method as well 🙂
dvPortgroupFromUUID vs dvPortgroupFromMOID
|
Thanks @catsby! |
ghost
locked and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The additions that are in #201 dictate the basis for how we will be
working with vSphere networks in the future - any resource that requires
a network for a backing (ie: virtual ethernet cards, VMkernel nics, etc)
will require a MOID to some sort of network, versus the name itself,
allowing us to circumvent actually searching for the network in the
downstream resource itself. Searching would be circumvented altogether
in the case of DVS portgroups being managed by TF completely as we would
just pass the MOID to the downstream resource.
The current behaviour of the
vsphere_distributed_port_groupresource isto use the
keyattribute in the MO as the ID of the resource, which isdocumented in the API as the UUID of the DVS port group, although in
reality it actually seems to be the MOID, which allows #201 to work
without issue right now. However, in order to guarantee that things will
be stable in the long run, we need to be sure we are using the right
values, so this update changes the ID to be the MOID of the object
itself.
keyis now being exported as a computed attribute of the samename.