Public bug reported: The user story is: Users can see human-readable security group descriptions in Horizon because the security group model contains a description field, but no such field exists for security group rules. This makes it very confusing for users who have to manage complex security groups.
I agree that one could encode descriptions as tags, but the problem I see is that API consumers(Horizon, Users) would have to agree on some common encoding. For example... To expose a security group rule description in Horizon, horizon would have to apply and read tags like 'description:SSH Access for Mallory'. With a tags-based implementation, if a user wants the description for a security group rule via the API, they have to get the security group, then filter the tags according to whatever format horizon chose to encode the description as. This is in contrast to getting the description of a security group: Get the security group and access the description attribute. I think that resource tags are great, but this seems like a non-intuitive workaround for a specific data model problem: Security Groups have descriptions, but Security Group Rules do not. A discussion is under way in the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2015-September/074046.html ** Affects: neutron Importance: Undecided Assignee: Li Ma (nick-ma-z) Status: New ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) => Li Ma (nick-ma-z) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1496705 Title: RFE: a common description field for Neutron resources Status in neutron: New Bug description: The user story is: Users can see human-readable security group descriptions in Horizon because the security group model contains a description field, but no such field exists for security group rules. This makes it very confusing for users who have to manage complex security groups. I agree that one could encode descriptions as tags, but the problem I see is that API consumers(Horizon, Users) would have to agree on some common encoding. For example... To expose a security group rule description in Horizon, horizon would have to apply and read tags like 'description:SSH Access for Mallory'. With a tags-based implementation, if a user wants the description for a security group rule via the API, they have to get the security group, then filter the tags according to whatever format horizon chose to encode the description as. This is in contrast to getting the description of a security group: Get the security group and access the description attribute. I think that resource tags are great, but this seems like a non-intuitive workaround for a specific data model problem: Security Groups have descriptions, but Security Group Rules do not. A discussion is under way in the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2015-September/074046.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1496705/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
