keypair-list should allow you to specify a user

Bug #1655062 reported by Javier Diaz Jr
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Won't Fix
High
Alexey Stupnikov

Bug Description

Request to backport https://bugs.launchpad.net/nova/+bug/1182965 into MOS 8.0 update

Detailed bug description:

Bug mentioned provides fix to allow for `nova keypair-list --user` functionality to work. As of MOS 8.0 MU3 this code is not yet implemented into MOS and as such this command fails.

Steps to reproduce:

Execute `nova keypair-list --user <user>` from MOS 8 CLI

Expected results:

Should provide list of keypairs for that specific user.

Actual result:

Nova CLI does not recognize argument --user

Reproducibility:

100%

Workaround:
None that I know
Impact:
Makes management of keypairs somewhat difficult for customer.

Description of the environment:
- Operation system: Ubuntu 14.04
- MOS 8.0

summary: - keypair-list should allow you to specify a user or all-users Edit
+ keypair-list should allow you to specify a user
Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :
Changed in mos:
status: New → Confirmed
Changed in mos:
importance: Undecided → High
assignee: nobody → MOS Maintenance (mos-maintenance)
Roman Rufanov (rrufanov)
tags: added: ct1
Changed in mos:
milestone: 8.0-updates → 8.0-mu-4
Changed in mos:
assignee: MOS Maintenance (mos-maintenance) → Alexey Stupnikov (astupnikov)
Revision history for this message
Alexey Stupnikov (astupnikov) wrote :

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

Revision history for this message
Alexey Stupnikov (astupnikov) wrote :

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/

Revision history for this message
Alexey Stupnikov (astupnikov) wrote :

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

Changed in mos:
status: Confirmed → Won't Fix
milestone: 8.0-mu-4 → 8.0-updates
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.