-
Notifications
You must be signed in to change notification settings - Fork 452
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
Add Custom Attribute resource and data source #229
Conversation
Wow @rmbrad, this would be definitely something that I think we would be interested in - it would be a great compliment to the current tagging support! 👍 I will hold off on my review until you have time to finish the tests and the docs. 🙂 And thank you! |
390846d
to
d77778b
Compare
@vancluever Finally got around to finishing off the documentation and tests. Let me know if there's anything I need to update after you get a chance to review. |
Hey @rmbrad - just had a minute to go over the docs now. I noticed that the only resource to have custom attribute added to it so far has been virtual machines. Can you work to add the support to other resources? It might help to spin off the common functionality like we do with tags - see Once #244 is in we will need to re-visit adding this to the new VM resource, so this will probably go in sometime after that gets merged. Thanks! |
Hi @vancluever. No problem, I'll start adding support for other resources this week. |
6d37a4c
to
a1a1be9
Compare
@rmbrad I just did a quick once-over on your progress and I just wanted to say it's looking awesome! 👍 Looks like you are making some pushes still so I'll wait till it's all settled before I start the review - let me know when you are ready! |
PS: One thing I did want to say/ask - have you tested this at all on ESXi? I have to double check, but if custom attributes are not supported on ESXi (as in the same fashion as tags), we need to make sure we skip this functionality and prohibit its use when connected to ESXi directly. There is a small helper in Looking forward to getting this in! |
@vancluever Thanks! I just need to add support for the datastore resources to achieve parity with the tag support. I've been running all tests against vCenter and not ESXi directly, but will be setting up a new ESXi instance for testing the VMFS datastore support; so that will allow me to verify whether ESXi supports custom attributes or not. I'm hoping to have everything ready for review by early next week, at this point it's only the testing that takes time as all logic is now in the helper. |
adebca9
to
e8dc3f0
Compare
Hey @vancluever - I believe this PR should now be ready for review. I've added support for custom attributes to all resources that supported tagging. Custom attributes are unsupported on direct ESXi connections, so I added the necessary checks similar to what is done for tagging support. Let me know if there's anything else needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @rmbrad - this looks really great - well done!
I have some questions and change requests inline before I go ahead and merge and smoke test it with some real-world configs.
One thing outside of this that I just want to double check - have you tested removing all tags from a resource, after they have been added? This was a pitfall we missed on tags I want to make sure we don't necessarily miss again.
I will make a note to review this again in the next couple of days (including actually testing it with real config).
Thanks for your patience with timing on this as well!
"github.com/vmware/govmomi/vim25/types" | ||
) | ||
|
||
// vSphereCustomAttributeKey is the string that should always be used as the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this needs to be changed to match the name of the identifier:
// ConfigKey is the string...
// resources. | ||
const ConfigKey = "custom_attributes" | ||
|
||
// customAttributesSchema returns the schema for custom attribute configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
// ConfigSchema returns the schema...
|
||
resource "vsphere_datacenter" "testDC" { | ||
name = "testDC" | ||
custom_attributes = "${map(vsphere_custom_attribute.terraform-test-attribute.id, "value")}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice the pattern of using the map
interpolation function is present in tests quite a bit. I'm not too sure if this works, but have you just tried:
resource "vsphere_datacenter" "testDC" {
name = "testDC"
custom_attributes = {
"${vsphere_custom_attribute.terraform-test-attribute.id}" = "value"
}
}
I would prefer that if it works - leaving more complicated scenarios using interpolation to any individual practitioner's use case 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, use of the map
function bothers me as well; but unfortunately interpolation doesn't work for map keys in resources as mentioned here hashicorp/terraform#14516 (comment) 😞.
One work around I often use is to place the definition of the custom attribute map in a locals block, where map keys are interpolated (keys will also be interpolated when passing to a module) as follows:
locals {
dc_attrs = {
"${vsphere_custom_attribute.terraform-test-attribute.id}" = "value"
}
}
resource "vsphere_datacenter" "testDC" {
name = "testDC"
custom_attributes = ${local.dc_attrs}
}
If you would prefer I can update the tests to work that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks a lot cleaner 🙂 and we also use the map assignment pattern in other places like you type there (not necessarily in the vSphere provider, but elsewhere in TF-land).
@@ -171,6 +171,53 @@ func TestAccResourceVSphereDistributedPortGroup(t *testing.T) { | |||
}, | |||
}, | |||
}, | |||
{ | |||
"single_attribute", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to be more descriptive in the sub-tests here - tag is descriptive enough, but attribute has meaning in TF itself - ie: a resource attribute. Maybe something like "single custom attribute", etc.
@@ -46,6 +46,12 @@ The following arguments are supported: | |||
~> **NOTE:** Tagging support is unsupported on direct ESXi connections and | |||
requires vCenter 6.0 or higher. | |||
|
|||
* `custom_attributes` - (Optional) Map of custom attribute ids to value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a link to directions on how to apply custom attributes similar to what we have for tags here?
|
||
## Argument Reference | ||
|
||
* `name` - (String, required) The name of the custom attribute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recently standardized on a new naming convention for attributes that I want to make sure is followed - the VM resoruce has a good layout of the format. An example is below:
some_attr
- (Required or Optional) Does some thing. Forces a new resource if changed (if this actually is aForceNew
) argument.
e8dc3f0
to
6ee86c1
Compare
Hi @vancluever, I've rebased the PR on master and believe I have addressed all your comments, with exception of the use of the |
6ee86c1
to
9116fb9
Compare
Just a couple of fixes to the example, formatting fixes and a shuffle of where the links are in the sidebar to keep the alphabetical arrangement.
@rmbrad I've done my final review and just make a couple of documentation corrections, but it largely looked good! I had a second thought about the tests regarding keeping the Anyway, thank you very much for this - this is a great PR and we appreciate the contribution! Well done! |
This allows management of Custom Attributes and allows their values to be specified on VMs satisfying #120. Specifically it adds a
vsphere_custom_attribute
data source for using predefined attributes, avsphere_custom_attribute
resource for managing new custom attributes using Terraform, and acustom_attributes
argument on VM resources for specifying custom attribute values.Still need to add documentation and tests, which I can work on if you're interested in merging.