The policies parameter has been replaced with the
policy parameter since Nova API version 2.64[1]

This commit adds a check to make sure the correct parameter is used.

[1]https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id59

Change-Id: Ia37beb7790884d6d15bec45074f446e64af1a2aa
Story: #2008041
Task: #40703
(cherry picked from commit ed6d8d941104c60f447de852582eb9388b9d2e73)

The policies field has been replaced with the
policy field since Nova API version 2.64[1]

This commit adds a check to make sure the correct field is used.

[1]https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id59

Change-Id: I06d3211937d822c26070b7f8ad757c365dcbb1bb
Story: #2007822
Task: #40101
(cherry picked from commit 51a1ea65f4d095b073381200e5268f909bf360de)

This is a work to switch OSC from using glanceclient to OpenStackSDK.

With this change only v2 is using OpenStackSDK. V1 is still using
glanceclient and will be switched in a separate change.

Remove the direct depend on keystoneauth- let that flow through
openstacksdk.

Depends-on: https://review.opendev.org/#/c/698972
Change-Id: I36f292fb70c98f6e558f58be55d533d979c47ca7

Does what it says on the tin. This action was added to osc-lib in change
If73cab759fa09bddf1ff519923c5972c3b2052b1.

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

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 <sfinucan@redhat.com>
Story: #2006628
Task: #36840
Related-Bug: #1845322

1. As mentioned in [1], we should avoid using six.iteritems to achieve
   iterators. We can use dict.items instead, as it will return iterators
   in PY3 as well. And dict.items/keys will more readable.

2. In py2, the performance about list should be negligible,
   see the link [2].

[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html

Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: I4b9edb326444264c0f6c4ad281acaac356a07e85
Implements: blueprint replace-iteritems-with-items

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

Added ``--disable-delete-on-termination`` and
``--enable-delete-on-termination`` options to the
``openstack server add volume`` command that enables users to mark
whether to delete the attached volume when the server is destroyed.

Depends-On: https://review.opendev.org/#/c/681267/

Part of blueprint support-delete-on-termination-in-server-attach-volume

Change-Id: I6b5cd54b82a1135335a71b9768a1a2c2012f755b