[RFE] Tag mechanism supports all resouces with standard attribute.

[Na Zhu]

Currently, neutron resources network, subnet, subnetpool, port, and routers support tag, floatingip does not support tag. Tag is useful for floatingip, users can use floatingip tag to identify what applications the floatingip are used for.

Add tag to floatingip is useful.

[Hirofumi Ichihara (ichihara-hirofumi)]

I think that tagging should support all resources.

[Akihiro Motoki (amotoki)]

Agree. I think tagging should be supported for all resources like other standard attributes. I am not sure there are resources which the tag mechanism does not fit.

[Hirofumi Ichihara (ichihara-hirofumi)]

Tag mechanism provides an identifier to specific resource in many resources so I think that tag mechanism doesn't fit network resource which has one resource only. Now there isn't such resource in resouces supporting standard sttribute.

[zhaobo (zhaobo6)]

It's good to go. :)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/460391

[Hirofumi Ichihara (ichihara-hirofumi)]

There is a project depends on 'tag' and 'tag-ext' extension[1]. I have a plan that I'll add new extension supports standardattr resources except resources supported by 'tag' and 'tag-ext' and then I'll remove 'tag' and 'tag-ext' once we remove the dependency on two old extensions from Kuryr.

[1]: http://git.openstack.org/cgit/openstack/kuryr-libnetwork/tree/kuryr_libnetwork/controllers.py#n75

[Akihiro Motoki (amotoki)]

I am fine with the direction to support tag for all resources.

On the other hand, status "In Progress" is out of radar of the drivers team. I think it is better to be discussed in the drivers meeting for fast approval.

[Kevin Benton (kevinbenton)]

This sounds good to me. We already have the database infrastructure in place for this so it's just a matter of the API plumbing. We can discuss in next drivers meeting.

[Ihar Hrachyshka (ihar-hrachyshka)]

Problem is, there is no clear definition of 'all resources' for neutron, since we allow for plugins into api layer. So we may still need to enlist all resources we envision.

[Hirofumi Ichihara (ichihara-hirofumi)]

I hope that this RFE is discussed on Driver team so remark Triaged.

[Kevin Benton (kevinbenton)]

This looks good. The only concern Ihar wants addressed is that we statically list all of the API resources this supports rather than automatically supporting any standard attr resources. Even though this is already how revision_number and timestamps work, do not follow their examples because the API in neutron-lib should be static.

[Hirofumi Ichihara (ichihara-hirofumi)]

Thank you. I'm considering the point. We don't want to add new extension(e.g. tag-qos, tag-agent, tag-meter) every time we add tag support for new resource. I think that this proposal doesn't change Tag API definition even if we add standard attr support to a resource. However, tag support is added to the resource automatically.

[Hirofumi Ichihara (ichihara-hirofumi)]

I also consider which resource really needs tag support in standard attr resources. For example, security group rule and segment seem unnecessary.

[Hirofumi Ichihara (ichihara-hirofumi)]

> I think that this proposal doesn't change Tag even if we add standard attr support to a resource.
My comment was bad. It's untrue.

I'm bothered that automatic tag support vs static tag support. Automatic tag support means that a new resource model with HasStandardAttributes is added and then automatically tag support is added to the resource. This is very easy but the API definition is dynamic. Static tag support means that developer must implement new extension and new API definition every time they add tag support for new resource. This is very verbose because we will have many tag extentions(e.g. tag-security-group, tag-qos, tag-floatingip, etc) but the API definitions is static.

When I added tag-ext, I adopt the latter because I thought that a few resources only need tag support. However, we got new requirement to entend tag support. I think that automatic tag support is reasonable although I know that basically it's wrong.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/479995

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/460391
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=96f0142b8089a85f1a031f236c6d39fd463bf86c
Submitter: Jenkins
Branch: master

commit 96f0142b8089a85f1a031f236c6d39fd463bf86c
Author: Hirofumi Ichihara <email address hidden>
Date: Fri Jun 16 16:46:37 2017 +0900

    Tag mechanism supports resources with standard attribute

    Tag mechanism supports network, subnet, port, subnetpool
    router resources only. This patch allow tag mechanism to support
     resources with standard attribute.

    Two old extenions are kept because of backward compatibility.
    They will be removed in Queens release.

    APIImpact: Tag is supported by resources with standard attribute
    DocImpact: allow users to set tags on resources with standard attribute

    Change-Id: Id7bb13b5beb58c313eea94ca03835d3daf5c94bc
    Closes-Bug: #1682775

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b3 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/479995
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=140b99812efc41a8fe987be4f93af38a3c74ecfd
Submitter: Zuul
Branch: master

commit 140b99812efc41a8fe987be4f93af38a3c74ecfd
Author: Hirofumi Ichihara <email address hidden>
Date: Tue Sep 19 15:20:14 2017 +0900

    Add API tests for Tag resource with standard attribute

    This patch added some api tests for tag resource with standard
    attribute, which are securitygroup, floatingip, trunk, and policy.

    In TagFilter test, identifier of resource was changed from name to
    id because floatingip doesn't have name attribute.

    Change-Id: I3a20abe00d4cb32b1a84aeb7b05429e776244c3e
    Related-bug: #1682775