This mostly reuses the existing tests for '--block-device-mapping',
which can hopefully be removed at some point in the future.

This highlights two issues with the implementation of this option.
Firstly, the 'boot_index' parameter is not required so don't mandate it.
Secondly, and more significantly, we were defaulting the destination
type for the 'image' source type to 'local'. Nova only allows you to
attach a single image to local mapping [1], which means this default
would only make sense if you were expecting users to use the
'--block-device' option exclusively and omit the '--image' option. This
is the *less common* case so this is a bad default. Default instead to a
destination type of 'volume' like everything else, and require users
specifying '--block-device' alone to pass 'destination_type=local'
explicitly.

[1] https://github.com/openstack/nova/blob/c8a6f8d2e/nova/block_device.py#L193-L206

Change-Id: I1718be965f57c3bbdb8a14f3cfac967dd4c55b4d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Make use of 'FormattableColumn'-derived formatters, which provide better
output than what we were using before, particularly for the YAML output
format.

Change-Id: Id6d25a0a348596d5a0430ff7afbf87b049a76bc8
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Make use of 'FormattableColumn'-derived formatters, which provide better
output than what we were using before, particularly for the YAML output
format. For example, compare before for the 'server show' command:

  $ openstack --os-compute-api-version 2.79 server show test-server -f yaml
  ...
  addresses: private=fdff:77e3:9bb4:0:f816:3eff:fe6d:a944, 10.0.0.44
  flavor: disk='1', ephemeral='0', extra_specs.hw_rng:allowed='True', original_name='m1.tiny',
    ram='512', swap='0', vcpus='1'
  ...

To after:

  $ openstack --os-compute-api-version 2.79 server show test-server -f yaml
  ...
  addresses:
    private:
    - fdff:77e3:9bb4:0:f816:3eff:fe6d:a944
    - 10.0.0.44
  flavor:
    disk: 1
    ephemeral: 0
    extra_specs:
      hw_rng:allowed: 'True'
    original_name: m1.tiny
    ram: 512
    swap: 0
    vcpus: 1
  ...

Similarly, compare before for 'server list':

  $ openstack --os-compute-api-version 2.79 server list -f yaml
  - ...
    Networks: private=fdff:77e3:9bb4:0:f816:3eff:fe6d:a944, 10.0.0.44
    Power State: Running
    Properties: ''
    ...

To after:

  $ openstack --os-compute-api-version 2.79 server list -f yaml
  - ...
    Networks:
      private:
      - fdff:77e3:9bb4:0:f816:3eff:fe6d:a944
      - 10.0.0.44
    Power State: 1
    Properties: {}
    ...

We also fix the human-readable output for the 'tags' field.

Before:

  $ openstack --os-compute-api-version 2.79 server list
  ...
  | tags   | ['bar', 'foo']  |

After:

  $ openstack --os-compute-api-version 2.79 server list
  ...
  | tags   | bar, foo  |

Change-Id: I7a8349106e211c57c4577b75326b39b88bd9ac1e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

The 'os-agents' API was recently removed from nova [1]. Remove the
functional tests, since they will always fail going forward but will
continue to run on older stable branches.

Also Squeeze https://review.opendev.org/#/c/762559/ inside, since those
2 are simultaneously blocking gate

[1] https://review.opendev.org/#/c/749309/

Change-Id: I0bf7d4c0ba2a9d4637db0d209d8d52163d772f12
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

Do not stringify flavor properties to allow proper output formatting to
json/yaml/etc

Change-Id: I9f4c42acb85b726af87123134dd19de98fe95074

Fixes incorrect json output for 'openstack server show -f json'.
The security group json output groups all the json as one
for e.g. "security_groups": "name='group1'\nname='group2'"
The correct output should be
"security_groups" : [{"name" : "group1"}, {"name" : "group2"}]
properties and volumes_attached fields also has similar issue.

Story: 2007755

Change-Id: I1b1cac716329e0530400aff782c08000b21d8e1d

For a server booted from a volume, nova API does not store an image_id
and instead returns an empty string. Currently, openstackclient
similarly shows an empty string for Image Name and Image ID for servers
booted from volumes.

To aid CLI users in understanding the meaning of no image_id, we can
display the string "N/A (booted from volume)" in the image field if the
server was booted from a volume.

Change-Id: I9c62cf6fe23b2e934dcbf5ebbf706b2705d2e424

This patch removes using the "name" option for a marker when
--deleted is also used. The find_resource() function
that is being called does not correctly handle using the marker
as the "name" in the search when also using deleted=True.
One simple way to fix this is force the marker to only be an ID
when --deleted is used. This is how the nova client works.

Using the --deleted option is available to users with the admin
role by default. If you're an admin listing --deleted servers
with a marker by name, find_resource() is going to fail to find
it since it doesn't apply the --deleted filter to find_resource().

The find_resource() function is trying to find the marker server
by name if it's not found by id, and to find it by name it's
listing servers with the given marker as the name, but not
applying the --deleted filter so it doesn't get back any results.

In the story it was suggested modifying find_resource to include
the deleted query param when it's specified on the command line but
that didn't work because it still results in something like this:

http://192.168.1.123/compute/v2.1/servers?deleted=True&name=4cecd49f-bc25-4a7e-826e-4aea6f9267d9

It seems like there are bugs in find_resource().

Restricting the marker to be the server ID when listing deleted servers
is probably OK since if you're using --deleted you're an admin and you could
be listing across all projects and if you're filtering by a server across all
projects anyway (not that you have to, I'm just saying if you are), or even
showing a server in another project, you have to do it by id rather than name
because find_resource() won't find the server in another project by name, only ID.

story: 2006761
Task: 37258

Change-Id: Ib878982b1d469212ca3483dcfaf407a8e1d2b417

While investigating the referenced story/bug I noticed that
wait_for_status in
openstackclient.tests.functional.compute.v2.test_aggregate.AggregateTests
was doing a lot more than it should ever need to (it probably got copied
in from somewhere). The two places calling it only need to a) check the
output of `openstack aggregate show`, and b) try once -- since they just
got done creating the aggregate synchronously, there should never be a
need to delay/retry. So this commit removes the helper method and just
inlines the check.

At the same time, the addCleanup(aggregate delete) directives are moved
above their respective creates. This is a defensive best practice which
makes sure cleanup happens even if something fails very soon after the
actual back-end create (as was in fact the case with the referenced
bug/story).

It is unknown whether this will impact the referenced bug.

Change-Id: I0d7432f13642fbccd5ca79da9c76adfcbabb5fa9
Story: 2006811
Related-Bug: #1851391