Bug 1142536

The security groups should only be displayed for the current project, you shouldn't see more than one. It sounds like a bug where either 2 security groups are created when there should only be one, or when logging in as an admin the 'security group list' call is not properly scoped to the project (there's been other bugs like this with Neutron before, where by default the admin would see all resources even without specifying an "all tenants" flag of some sort, e.g. https://bugs.launchpad.net/horizon/+bug/1226224 ).

A workaround to get the id would be to click on "Manage rules" for the group and look at the URL.

Could you clarify what goal you were trying to achieve?

Is the problem that 2 'default' groups are displayed in the CLI and only one in the dashboard? Or that there were 2 security groups displayed in the dashboard when logged in as admin, too? Or that there are 2 default groups on the CLI and some didn't belong to the current tenant/project, but in Horizon it's scoped correctly to show only one group? If the latter it sounds to me like this would be more of a neutron bug, whereby it should restrict to the current tenant by default or provide an option to do so.

Hi Julie, The original task was to do some networking on the command line as admin, and I couldn't see which group belonged to which project (have raised a neutron-client bug as well). So then I opened up the dashboard, and couldn't see it there either. When logged in as admin, it only shows the group assigned to the admin project, I can't see that of the demo project, nor can I see the ID of the group to sort out the difference. Does that make sense?

Thank you for the reply Summer! From the dashboard perspective, only showing the security groups for the current project is the expected behaviour. Could you provide a link to the neutron client bug for reference?

It seems to me that it should be down to the Neutron Client to show some project context when the user is an admin and showing resources across projects, and that explicitly adding that information to the dashboard is more of a workaround.

I'm a bit concerned about adding the id to the listing because this is not something we do for any of the panels in the project dashboard and it gives a bit of a cluttered feel. If the workaround of looking at the URL isn't appropriate, maybe we could add it to the "Manage Security Groups Rules" header, after the group name between parenthesis? (See screenshot for an example)

Created attachment 938699 [details]
Security group - id in header

I understand why you wouldn't want to add clutter to the listed view, adding it to the header when you're managing one would be great! And I guess I just thought it would also be good for the admin to have a view of all groups in the same way they can see all instances. (Sorry, am in the middle of re-doing installs so can't provide a screenshot.)

I filed a bug upstream about adding the id to the page title.

For now I'm not convinced of the use of adding a panel to list all the security groups in Horizon (or keypairs, etc...). There's no particular operation that an admin can perform on them and they're unlikely to give visibility into a problem affecting the system (e.g. instances might get stuck, volumes might take too much space, etc), that would require admin intervention. If the RFE comes back again I'll happily consider myself corrected of course, but for now I don't think there's a strong use case or a good enough justification to add yet another panel of data to the admin dashboard.

This is implemented in Kilo, marked this as post

It's a general kilo fix; there was not patch included compared to last RHOS-7 build. I simply missed this bug for the GA.