Add support for neutron tags

[hardys]

Recently added gophercloud support for the neutron attributetags extension means we should be able to specify tags for neutron resources that support attributetags, so the created resources can be optionally tagged during resource create/update via terraform.

For example:

resource "openstack_networking_network_v2" "terraform" {
name = "terraform_test"
admin_state_up = "true"
tags = "${var.tags}"
}

tags should be optional and accept a list of strings - this is useful when you want to group neutron resources then later query for them by tag using the neutron API and server-side filtering by tags.

Affected Resource(s)

The affected resources will be the same as added to gophercloud via gophercloud/gophercloud#1286, e.g:

Router: https://github.com/openstack/neutron/blob/master/neutron/db/models/l3.py#L67
FloatingIP: https://github.com/openstack/neutron/blob/master/neutron/db/models/l3.py#L112
SecurityGroup: https://github.com/openstack/neutron/blob/master/neutron/db/models/securitygroup.py#L32
Port: https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L115
Subnet: https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L210
SubnetPool: https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L250
Network: https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L278
QoS/RBAC Policy: https://github.com/openstack/neutron/blob/master/neutron/db/qos/models.py#L36
Trunk: https://github.com/openstack/neutron/blob/master/neutron/services/trunk/models.py#L49

Note that Trunk tag support is being added via https://github.com/terraform-providers/terraform-provider-openstack/pull/446 so this issue can track adding tag support to the remaining resources.

Checklist

• Router (PR Add tags support for Neutron Routers #467)
• FloatingIP (PR Add tags support for Neutron floatingips #466)
• SecurityGroup (PR Add tags support for Neutron Security Groups #463)
• Port (PR Add tags support for Neutron Ports #461)
• Subnet (PR Add tags support for Neutron Subnets #459)
• SubnetPool (PR Add tags support for Neutron Subnetpools #460)
• Network (PR Add tags support for Neutron Networks #454)
• QoS/RBAC Policy (Not currently supported in terraform-provider-openstack AFAICS)
• Trunk (PR Network resource - Trunk #446)

References

gophercloud/gophercloud#1286
https://docs.openstack.org/neutron/pike/contributor/internals/tag.html
gophercloud/gophercloud#1285
https://github.com/terraform-providers/terraform-provider-openstack/pull/446

[hardys]

Note I'll rebase this on #446 as there is a common function to extract the tag list/slice from resource data that I also have in my branch.

[jtopjian]

@hardys Copying the comment from #454:

would you prefer one PR per resource

Yes, let's do one PR per resource and you can link them all to this issue.

We were able to add tag support to Gophercloud in a few large commits, but Gophercloud is not meant to be end-user facing, so we assume the developer reads the godoc or code itself.

Terraform is end-user facing, so there's more we'll want to do. For each resource:

1. Add the new schema item to the resource.
2. Add the new schema item to the data source, if one exists.
3. Add a test for both the resource and data source to make sure tags works (if a test file already has a 2-step _basic and _update test, you can amend these for "tags" instead of creating a whole new test). Making sure test cases exist for each resource is important so we can compare with any reported issues.
4. Update the documentation for both the resource and data source.

Bundling all of the above into one PR should be fine. If you want to do the resource and data source separately, that works, too, though I imagine vendoring might get in the way of this.

As long as you vendor on the same commit, you should be able to open multiple PRs for different resources at once, though I recommend waiting until OpenLab finishes testing so it doesn't get overloaded.

Thoughts?

[hardys]

As long as you vendor on the same commit, you should be able to open multiple PRs for different resources at once, though I recommend waiting until OpenLab finishes testing so it doesn't get overloaded.

Thoughts?

This sounds fine to me, thanks for the feedback.

I'll rebase the networks patch today and start preparing the other resources locally - to avoid CI overload I'll push only the networks resource, then we can iterate on review feedback and I'll apply any common changes to the rest of the series before pushing (and then only a few at a time).

Hopefully that will help with the review & CI overhead since most of the patches will be essentially the same after we get the initial review nits ironed out.

[hardys]

On closer inspection it seems qos/rbac policies aren't currently supported by terraform-provider-openstack so I'll strike that item off the issue and we can consider adding it at a later date if needed.

[hardys]

All checklist items completed so I'll close this now, thanks for the prompt reviews! :)

[hardys]

Hi @jtopjian thanks very much for the prompt reviews on this series, much appreciated! 🍰

I was wondering when you next plan to tag a release, as I need to consume these new interfaces ref openshift/installer#391 (our CI only consumes tagged releases), thanks for any ETA you can provide!

[jtopjian]

@hardys No problem at all - thank you for working on this.

We just had a release last week, so we'll want to have a few more features/fixes added. Maybe the week after next. But if that's going to block some other work, I can see about doing a release next week - the schedule is totally arbitrary, anyway.

[hardys]

@jtopjian Thanks for the reply - sometime in the next 1-2 weeks would be great, my openshift PR isn't super-urgent but I think the CI on it will be blocked until we pick up a new release, we can get reviews & local testing under-way in the meantime! :)