delta/openstack/python-openstackclient.git/openstackclient/compute/v2/server.py, branch stable/rocky

Stop silently ignoring invalid 'server create --hint' options

2020-02-19T13:33:58+00:00

The '--hint' option for 'server create' expects a key-value pair like so:

  openstack server create --hint group=245e1dfe-2d0e-4139-80a9-fce124948896 ...

However, the command doesn't complain if this isn't the case, meaning
typos like the below aren't indicated to the user:

  openstack server create --hint 245e1dfe-2d0e-4139-80a9-fce124948896

Due to how we'd implemented this here, this ultimately results in us
POSTing the following as part of the body to 'os-servers':

  {
    ...
    "OS-SCH-HNT:scheduler_hints": {
      "245e1dfe-2d0e-4139-80a9-fce124948896": null
    }
    ...
  }

Which is unfortunately allowed and ignored by nova due to the use of
'additionalProperties' in the schema [1]

Do what we do for loads of other options and explicitly fail on invalid
values. This involves adding a new argparse action since none of those
defined in osc-lib work for us. This is included here to ease
backporting of the fix but will be moved to osc-lib in a future patch.

[1] https://github.com/openstack/nova/blob/19.0.0/nova/api/openstack/compute/schemas/servers.py#L142-L146

Change-Id: I9e96d2978912c8dfeadae4a782c481a17cd7e348
Signed-off-by: Stephen Finucane 
Story: #2006628
Task: #36840
Related-Bug: #1845322
(cherry picked from commit ea27ebb0f918db9eab2f5751a1b065818faa0e6d)
(cherry picked from commit 576d9ecfd0ac27611ec89af6d34e7378b7a39fb3)
(cherry picked from commit 38e1274f478219bee8899b6c9eaa09dbfd03bbcd)

Fix BFV server list handling with --name-lookup-one-by-one

2019-07-22T20:00:16+00:00

When the --name-lookup-one-by-one option passed to the 'server list'
command, the image and flavor names will be looked up for each
server being listed instead of fetching all image/flavor names.

The current code assumes all servers have an image attribute, but
servers booted from volumes have no image, so the following error is
raised when listing BFV servers with --name-lookup-one-by-one:

  AttributeError: ('unicode'|'str') object has no attribute 'get'

The error occurs when the code attempts server.image.get('id').

This fixes the --name-lookup-one-by-one code not to assume an image
for a server. The unit tests for 'server list' have also been
robustified to feature one BFV server to enhance our test coverage.

Story: #2006063
Task: #34777

Change-Id: I312c971346c7ded93f6fcaa515098554b8580295
(cherry picked from commit bfc34e11b3437506508b3e120accc0e212268ac6)
(cherry picked from commit 83359fbe4fd7e5850abd45a467bf197c284519b1)

Add --name-lookup-one-by-one option to server list

2019-07-22T19:56:11+00:00

usually in a big cloud there are many images and flavors,
while each given project might use only some of those.

This patch introduces '--name-lookup-one-by-one' argument to
server list command (mutually exclusive with '--no-name-lookup')

When provided (or either '--image' or '--flavor' is specified) to the
`server list` command, name resolving for
corresponding entity is now using targeted GET commands instead of
full entities list.

In some situations this can significantly speedup the execution of the
`server list` command by reducing the number of API requests performed.

Change-Id: I59cbf3f75c55e5d3747654edcc9be86ad954cf40
Story: #2002039
Task: #19682
(cherry picked from commit e782f49927a6b142a35f85a1a4a759fd2b1ceedf)

Handle multiple ports in AddFloatingIP

2018-11-08T18:03:13+00:00

AddFloatingIP refers to an old nova proxy API to neutron that was
deprecated in nova. The neutron API for floating IP associate requires
a port to be specified. Currently, the code is selecting the first port
if the server has multiple ports. But, an attempt to associate the
first port with a floating IP can fail if the first port is not on a
network that is attached to an external gateway.

In order to make the command work better for users who have a server
with multiple ports, we can:

  1. Select the port corresponding to the fixed_ip_address, if one was
     specified

  2. Try to associate the floating IP with each port until one of the
     attempts succeeds, else re-raise the last exception.
     (404 ExternalGatewayForFloatingIPNotFound from neutron)

This also fixes incorrect FakeFloatingIP attributes that were being set
in the TestServerAddFloatingIPNetwork unit tests, which were causing
the tests to use None as parsed args for ip-address and
--fixed-ip-address and thus bypassing code in the
'if parsed_args.fixed_ip_address:' block.

Task: 27800
Story: 2004263

Change-Id: I11fbcebf6b00f12a030b000c84dcf1d6b5e86250
(cherry picked from commit 013c9a4f3a44cb0b81fc7affe9b933e701cb5dba)

Default --nic to 'auto' if creating a server with >= 2.37

2018-10-25T20:25:28+00:00

Compute API version >= 2.37 requires a 'networks' value in
the server create request. The novaclient CLI defaults this
to 'auto' if not specified, but the novaclient ServerManager.create
python API binding code does not, as it wants clients to be explicit.

For the purposes of the OSC CLI, we should follow suit and if the
user is requesting OS_COMPUTE_API_VERSION>=2.37 without specific
nics, we should just default to 'auto'.

Change-Id: Ib760c55e31209223338a4086ff1f4fee88dc6959
Closes-Bug: #1750395
(cherry picked from commit 1008544882fbdae16b045abca05cf3e2e8a14787)

Don't sent disk_over_commit if nova api > 2.24

2018-07-24T15:09:27+00:00

In API microversion 2.25 Nova removed the disk_over_commit parameter
to the live migration server action. This patch makes sure that we
don't include it in our request if we're running with 2.25 or higher.

Story: #2002963
Task: #22966
Change-Id: I1bbdd33be96d82422a05982508e370237c3560f3

Skip calls to glance and nova when got no servers

2018-07-09T12:07:24+00:00

save (potentially many) HTTP calls to Glance API for image list
and a call to Nova API for flavor list when the server list
actually returned no servers.

Change-Id: I93a56138c50b82fb4dce67a2f788107f71c5f423
Story: #2002039
Task: #19681

Merge "Display private flavors in server list"

2018-06-29T13:57:45+00:00

Fix server show for microversion 2.47

2018-06-08T19:52:31+00:00

Compute API version 2.47 embeds the server's internal
flavor in the response. The original flavor id is not
preserved since it could have changed if the flavor
was deleted and re-created after the server was created,
which was the dreaded Horizon "Edit Flavor" issue.
So the flavor dict in the server response is a dict of
information about the flavor representing the server
"right now" excluding the id. The original flavor name
is shown though along with the ram/disk/vcpu etc
information.

The server list command has a similar issue which
will be fixed in a follow up change.

Change-Id: I1a92999758006d02567c542b6be8902a049899cc
Task: 13864
Story: 1751104

Optimize _prep_server_detail to avoid redundant find_resource

2018-06-08T15:46:29+00:00

When showing a server or doing a rebuild, we already have
the latest version of the server so _prep_server_detail
getting the server again is an unnecessary performance hit.

ShowServer is pretty obvious here. For RebuildServer, the
compute API actually refreshes the server before returning
it in the response, so the client already gets the latest
when the rebuild call returns.

The only other usage of _prep_server_detail that does require
a refresh is CreateServer since the POST /servers response is
a minimal version of the server object.

This adds a new refresh kwarg, backward compatible by default,
to _prep_server_detail but changes ShowServer and RebuildServer
to no longer refresh.

Change-Id: Ib1c9c424ed1cafc2dfd8be90af8de8a774bdfbf0