please support hypervisor servers command

Bug #1418369 reported by gustavo panizzo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-openstackclient
Won't Fix
Medium
Lin Hua Cheng

Bug Description

hello i want to ask you to support (nova) hypervisor servers command, openstackclient csv output is very useful for scripts and that piece is missing.

thanks!

Revision history for this message
Steve Martinelli (stevemar) wrote :

Looks like there is support for `nova hypervisor-show` and `nova hypervisor-list` which are `openstack hypervisor show` and `openstack hypervisor list` respectively.

Are you specifically calling out for the other commands, like: hypervisor-servers, hypervisor-stats, and hypervisor-uptime ?

Revision history for this message
gustavo panizzo (gfa) wrote :

correct, i'm asking for nova hypervisor-servers command

Changed in python-openstackclient:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → m8
Changed in python-openstackclient:
assignee: nobody → Lin Hua Cheng (lin-hua-cheng)
Revision history for this message
Dean Troyer (dtroyer) wrote :

We copied the 'hypervisor' term from nova, but I don't think it is the best name for what we are displaying. Maybe it is, I could be convinced either way. Something to consider.

In any case, the 'nova hypervisor-servers' command output is a list of server instances, so I'd suggest this be implemented as an option to 'server list'. Some other changes too, if possible easily via the API, display the server name rather than the EC2 name, and I'm not sure that both hypervisor id and name are both required, at least in the short output field list.

server list [--hypervisor]

Does the existing --host filter apply to this command?

Changed in python-openstackclient:
status: Confirmed → Triaged
Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

For the hypervisor show/list, I think we are fine keeping the term "hypervisor", we also used the same term in Horizon. We got some term consistency here..

Yes, the existing "server list" do support the --host filter. Here is an example output.

(openstack) server list --host vm-ubuntu
+--------------------------------------+-------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------+--------+------------------+
| 075920f8-73dc-4693-b62c-1c10f8ea3831 | test2 | ACTIVE | private=10.0.0.3 |
| 14160701-da76-45df-8535-a9380114c4b4 | test | ACTIVE | private=10.0.0.2 |
+--------------------------------------+-------+--------+------------------+

Here is the output of the "hypervisor-servers" command:

$ nova hypervisor-servers vm-ubuntu
OS Password:
+--------------------------------------+-------------------+---------------+---------------------+
| ID | Name | Hypervisor ID | Hypervisor Hostname |
+--------------------------------------+-------------------+---------------+---------------------+
| 14160701-da76-45df-8535-a9380114c4b4 | instance-00000001 | 1 | vm-ubuntu |
| 075920f8-73dc-4693-b62c-1c10f8ea3831 | instance-00000002 | 1 | vm-ubuntu |
+--------------------------------------+-------------------+---------------+---------------------+

If we go with supporting "server list [--hypervisor]", it would actually be more complicated to implement. We have to do N +1 queries, where N is the number of hypervisor.

It would look something like:
a.) get all hypervisor 'hypervisor-list`
b.) get servers by hypervisor 'hypervisor-servers <host>`
c.) map the value from b.) (hypervisor name + instance id) to the list of instances

I would imagine the user would be doing this steps to do a lookup of instance by hypervisor:
1.) get a list of hypervisor
2.) list the servers for the hypervisor they are interested in

so keeping the command in the `hypervisor` might be more intuitive.

how about adding 'hypervisor server <hostname>` instead?

Revision history for this message
Steve Martinelli (stevemar) wrote :

fwiw, i like keeping the term hypervisor as an object, and don't like the idea of 'os server show --hypervisor'

Revision history for this message
gustavo panizzo (gfa) wrote :

openstack server list --host <hypervisor> does what i want
IMHO mimic nova, and other commands, switches is better

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

gustavo: "openstack server list --host <hypervisor>" is already available, do you still see a need for this request?

Revision history for this message
gustavo panizzo (gfa) wrote :

@linhua i think you can close the request, or leave it as RFI in case you plan to provide os hypervisors command later.

thanks

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

@Dean, Steve: Should I just move this to Won't Fix since the functionality is actually there?

Revision history for this message
Steve Martinelli (stevemar) wrote :

since `nova hypervisor-servers` is covered by `os server list` then that just leaves `nova hypervisor-stats`, and `nova hypervisor-uptime`, which i feel are going to overlap with `os usage show` if that is the case we can mark this as wont' fix

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

the usage command aggregates the resource usage by project, while the hypervisor command provides the usage by hypervisor plus it include the total available resource. It provides an extra information useful for the user.

I'll mark this bug as won't fix and open a new bug to add support for hypervisor-stats and hypervisor-uptime command

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

Steve: I don't have access to set the status to Won't Fix. Can you update it please?

Opened https://bugs.launchpad.net/python-openstackclient/+bug/1423748 to add the hypervisor-stats and hypervisor-uptime support

Revision history for this message
Steve Martinelli (stevemar) wrote :

done, thanks for the detective work, lin.

Changed in python-openstackclient:
status: Triaged → Won't Fix
Dean Troyer (dtroyer)
Changed in python-openstackclient:
milestone: m8 → none
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.