Agreed it would be useful. It's currently quite costly to retrieve the name of the user since we only get an id back from the instance list (cf. https://github.com/openstack/horizon/blob/stable/folsom/horizon/dashboards/syspanel/instances/tables.py#L60)

Hm.  I see your point.

Can you request a database view that you can query against?

Horizon runs without database access at all. I'm not sure, if it is implemented in keystone to look up an ID.

I believe it's possible to do this but it doesn't scale well, which is why it was removed upstream. We're dependent on the existing client APIs to return that information in a more practical way.

I get that it's an expensive operation using the available api.  I also humbly request that it would be good to add new views and apis to make these features available to OpenStack admins.

I think this really is the kind of things the customisation module should be used for. You can find more information about it in the upstream docs at http://docs.openstack.org/developer/horizon/topics/customizing.html#modifying-existing-dashboards-and-panels .

In this case you would extend the table(s) you want to change in the overrides file, and then make sure the new classes are being used instead of the default Horizon ones:

    from django.utils.translation import ugettext_lazy as _

    from horizon import tables

    from openstack_dashboard.dashboards.admin.instances import tables as admin_tables
    from openstack_dashboard.dashboards.admin.instances import views

    # Extend the existing class
    class MyAdminInstancesTable(admin_tables.AdminInstancesTable):
        user = tables.Column("user_id", verbose_name=_("User"))

        class Meta(admin_tables.AdminInstancesTable.Meta):
            # Decide what columns to display, in which order, and/or
            # "remove" a column from the table (like e.g. image_name here)
            columns = ('tenant', 'user', 'ip', 'host', 'name',
                       'status', 'task', 'state', 'created')

   # Tell Horizon to use this new class instead for the Admin view
   views.AdminIndexView.table_class = MyAdminInstancesTable

The customisation module path in the local settings needs to be an importable Python module.

With regard to showing the user as username, you could do something similar to what is done for the project names ( https://github.com/openstack/horizon/blob/93d4285249/openstack_dashboard/dashboards/admin/instances/views.py#L101 ).

Keeping in mind that this doesn't scale well (cf. https://github.com/openstack/horizon/blob/93d4285249/openstack_dashboard/dashboards/admin/instances/tables.py#L123 ). I realise it is much more useful to see names rather than IDs, however we get the instances list with user ids from Nova, while the user names live in Keystone. These are 2 separate services with 2 separate databases and I'm not sure what can be done besides expensively correlating ids to names, which can be done in the customisation module if the performance hit is acceptable in your deployment.

With regard to the second request, I know of companies that would rely on the ssh key column in their workflow to derive information about an instance (e.g. these servers run with the production keys, these ones are test, these ones are personal dev accounts). I think there's no way for upstream to determine a default set of columns that will work for everyone, and rather than shuffling the columns every release, per-deployment customisations make more sense and should be used in this case.

I hope this helps. I'd like to close the bug with this workaround, and I'm happy to try and help if questions come up working with the customisation module. Thank you.

The upstream Feature Freeze for 6.0 was on September 4th, so I'm switching the flags (will move to 7.0 once the target is created). Now that we've clarified the goal into feasible tasks, I created the upstream tasks to track this and don't think I need any further information at this point, thank you.

There is a link to the Launchpad bug ID in the External Trackers, for adding a user details page: https://bugs.launchpad.net/horizon/+bug/1380595 . Looking at it now, there is an associated patch and it looks very close to being merged, so I would expect it to land in Kilo.

Users page feature was merged into kilo.

New features are not applicable for backports.

Fixed in Upstream Kilo, removing rhos-future flag.

Failed QA
========= 
python-django-horizon-2015.1.0-10.el7ost.noarch
openstack-dashboard-theme-2015.1.0-10.el7ost.noarch
openstack-dashboard-2015.1.0-10.el7ost.noarch

Tested with RHOS theme, there is no User column

From comment 20 and 21 above I was able to see that the upstream request https://bugs.launchpad.net/horizon/+bug/1380595 has been closed and is part as kilo.  From other comments I see they were looking for way to drill down to the user information associated with a instance from the Admin tab.  

Comment 10 provides an alternative using customization module (http://docs.openstack.org/developer/horizon/topics/customizing.html#modifying-existing-dashboards-and-panels) as way to get some of the details without upstream changes.

From the comments this RFE is looking to add a way to drill down to user information associated with an instance.

There is  from Admin tab -> Instances -> pick an instance -> action log

This page does show user ID for actions on the instance, but not a user name.

What is this RFE trying to address and what is expected to close out this RFE?

A user page was added upstream, displaying user info. That is exactly, what the title says here: Create a "User" page for linking IDs to names more easily.

It would be handy to have a list of instances run by the user <foo>

Nova exposes that function
nova list --user fac5fb85d6f64607bef7772f646f9ee6

[root@euler ~(keystone_admin)]# nova show 499026c1-f219-4027-b143-466220502d56
+--------------------------------------+----------------------------------------------------------+
| Property                             | Value                                                    |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig                    | 
......                                                          |
| user_id                              | fac5fb85d6f64607bef7772f646f9ee6                         |
+--------------------------------------+----------------------------------------------------------+

nova show also exposes the user_id.

since upstream believes, this rfe is implemented, there was no action on this during liberty cycle.

Either, we'll close it as implemented, or there should be clearly stated, what's missing and target release needs to be moved to 9.0

A proposal to solve this would be to add a link from the user id in the action log directly to the user. Adding the user name to the action log itself can't hurt.

For reasons listed above, adding the user id directly to the instances list would hurt performance.

Patch upstream missed Mitaka

Radomir can you see if there is anything we need to do for this?

There is a patch upstream, and it received some reviews (5 +1s), but there has been no activity since 4 months, and seems that no core reviewed it. I think I can pick it up, clean it up and fish for reviews.

I tried to move it to 11 but the rules engine moved it back.  Scott - what does "A1" mean?

Also how could this have FailedQA if QA Whiteboard says "NotStarted"

(In reply to Jason E. Rist from comment #34)
> I tried to move it to 11 but the rules engine moved it back.  Scott - what
> does "A1" mean?
> 
> Also how could this have FailedQA if QA Whiteboard says "NotStarted"

If you want to move it to 11, you need to add the "Triaged" keyword. (I've added it for you).

"A1" is an old designation we used to use for our planned maintenance/z-stream releases.

Adding a link to the user details page to the action log: https://review.openstack.org/#/c/396649/

The change has merged upstream.

How to test:

* Launch an instance.
* Go to the instance's details page.
* Switch to the action log tab.
* Verify that the UUID of the user is a link leading to the user's page.

The User ID is a string, and not a link.  This is version 11.0.1

The patch that implemented this got partially undone by the fix for this: https://bugs.launchpad.net/horizon/+bug/1667154

The link to the user page is not present under Project→Instances→instance→Action Log, but is there under Admin→Instances→instance→Action Log. That is because regular users don't usually have the permission to view the user page anyways.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1781