Description of problem: Thera are few nova CLI commands that use SERVER term instead of Instance Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.run (keystone_admin)]$ nova | grep server 2. you will get all the command using server definition 3. Actual results: Expected results: no server should be used only instance Additional info:
Moving this to python-novaclient. This is easy to fix as all the nova help is generated from docstrings of do_* functions in the shell.py. Should be fixed upstream first. Note that terms 'server' and 'instance' are used interchangeably throughout the nova codebase, and don't necessarily cause confusion as they are not ambiguous. Having said that - it makes sense to refer to the same thing by the same name at least in the command line utility.
I filled upstream bug for this: https://bugs.launchpad.net/python-novaclient/+bug/1156648
*** Bug 976437 has been marked as a duplicate of this bug. ***
Fix has been merged upstream. It will be included in next python-novaclient build.
Fix backported.
Updating Target Milestone for bug in erratum
Tested it on RHEL (RHOS-4.0) and it still has some occurrences of "instance" in host-evacuate and host-meta which were added upstream after the patch got merged. $ rpm -q python-novaclient python-novaclient-2.15.0-2.el6ost.noarch $ nova help | grep instance Update the VPN IP/port of a cloudpipe instance. cloudpipe-create Create a cloudpipe instance for the given project. cloudpipe-list Print a list of all cloudpipe instances. host-meta Set or Delete metadata on all instances of a host. instance-action Show an action. instance-action-list host-evacuate Evacuate all instances from failed host to specified Migrate all instances of the specified host to other
So I fixed this upstream but 2 mentions of "instance" were added since then with new upstream patches. Given the circumstances I'd still consider this bug fixed.
As Russel confirmed, "server" is predominant usage throughout OpenStack, also favoured in the upstream bug comment. Anyway, this isn't a matter of choosing a correct term. I changed all viable "instance" to "server" upstream and yet new "instance" strings appeared with new upstream patches. In other words, this is upstream matter which must be solved there. The burden of correcting these downstream is *not* worth the gain. To really fix this, convention would need to be chosen and enforced upstream.