keypair-list should allow you to specify a user

This code was not present in liberty: https://review.openstack.org/#/c/251486/
(https://bugs.launchpad.net/python-novaclient/+bug/1522424)

I checked nova API features added with the spec [1]. So Denis statement about lack of novaclient support is confirmed.

[1] https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/admin-query-any-keypair.html

INTRODUCTION

A capability to specify user ID in keypair-related operations was added with patch [1]. This patch adds the user-id option to novaclient syntax and bumps the Nova API microversion supported by novaclient. Nova API v2.10 should be supported by both novaclient and nova server to successfully use user IDs in keypair requests.

Client uses special request to find out the current version of nova server API. It uses the maximum microversion from server's response to build optimal request (the usage of many options and commands explicitly depends on the microversion recieved from server).

As Denis stated, Nova server shipped with MOS8 supports API v2.10, however there is another problem to solve on controllers: there are two nova API endpoints that can be used by a client: the one that doesn't support microversions (v.2.0, configured in MOS8 by default) and the one that does (so-called v2.1, it isn't configured in MOS8 by default). This issue should be solved by changing keystone endpoint (see example below).

An outdated novaclient is shipped with MOS8. It will take us to backport ~50 patches to add the support of API v.2.10. This can't be done in MOS8 because even if we will close our eyes on the size of backport, liberty upper-constraints still doesn't allow to do backport a fresh enough version of novaclient.

CONCLUSION

There are two problems in MOS8 that should be solved to get rid of this issue:

1. We use obsolete nova endpoint with incorrect API URL version suffix. Bug #1581459 reports this problem in MOS9. It looks like we can't solve this bug, since puppet manifest modification could break existing deployments. Example command (you probably should remove the old nova endpoint):

    openstack endpoint create --publicurl 'http://172.16.179.180:8774/v2.1/%(tenant_id)s' \
    --adminurl 'http://192.168.0.2:8774/v2.1/%(tenant_id)s' \
    --internalurl 'http://192.168.0.2:8774/v2.1/%(tenant_id)s' \
    --region RegionOne nova

2. We have to update novaclient. The issue here is that we can't just state API v2.10 support without backporting all features implemented between API v2.5 (supported by novaclient shipped MOS8) and API v.2.10 (I have tried different ways to solve this problem, but they didn't worked, or was too risky to use). IMO the optimal way to update novaclient is to use pip and virtualenv to locally install fresh novaclient (APIv.2.10 support was added in python-novaclient3.1, python-novaclient3.3.2 is used in MOS9). Example command sequence (you probably should make it a bit more customer-friendly to use):

    apt-get install python-pip
    apt-get install virtualenv
    mkdir testproject
    cd testproject/
    virtualenv test
    source test/bin/activate
    pip install python-novaclient
    cp ~/openrc ./
    source openrc

[1] https://review.openstack.org/#/c/251486/

Moving to Won't fix as it is impossible to add requested support in novaclient and there is a WA described in comment #3