This rather complex function has had stuff tacked on over the years.
Help make working with it a bit easier through liberal application of
whitespace and some nicer indentation. Some option help text is improved
based on changes to modern nova.
Change-Id: I8154dd395dd904c3bcd180a7d0f9037b7e0be64f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is equivalent to novaclient's 'live-migration-force-complete'
command.
Change-Id: Ic4dc639afa16cdf8c5a46774895e850d92985292
Story: 2007513
Task: 39293
Oslo things are really server-side oriented and are heavy-weight
for client things. Remove oslo.utils and just use iso8601 and
importlib directly. It's not actually a bad library, but pulling
it and its other deps in just for a couple of wrapper methods
is a bit much here.
oslo.i18n, fwiw, is lightweight and helpful.
Change-Id: I463993170c03a1d98c47ab6a3c19131b7fca1099
If we add a floating IP for the server with no fixed IP, CLI doesn't
report an error and nothing happens. The patch adds an error message
when the server which don't have fixed IP bind floating IP.
Change-Id: I400f2bab08521bb7fa443d87c7f45cc79eb80694
Task: 27941
Story: 2004346
With python3.x, classes can use 'metaclass=' instead of
'six.add_metaclass', 'six.iteritems' and 'six.iterkeys' can
be replaced by 'items' and 'keys', 'six.moves.urllib.parse'
can be replaced by 'urllib.parse', 'six.StringIO' and
'six.moves.cStringIO' can be replaced by 'io.StringIO',
'six.text_type' and 'six.string_type' are just 'str'.
Change-Id: I84848c0bf8ab3c36dd821141191e2725e4e3b58b
Add ``openstack server migration list`` to fetch server migrations.
Part of blueprint add-user-id-field-to-the-migrations-table
Change-Id: I15b4a5aca8d0dee59dd293e7b1c7272cdfbeea20
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
There was a problem that the '-image-property' option, which can be used
to create an instance, did not work as intended.
I found that there were two problems with this option.
First, I cannot select an image as its metadata.
The second is that when there are multiple images available, the desired
image may not be selected depending on the situation.
This patch solves these two problems.
I wrote the test case with these two problems considered together.
Change-Id: Ib2745d7e067056ff4ca8bfaf6cff492d0dacb73a
story: #2007860
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
Despite what the help text for this options says, the nova API only
accepts boolean values for this value and has done so since at least the
introduction of the 2.1 microversioned API. While it would be nice to
convert '--config-drive' to a boolean flag, we'd need to be able to
retain temporary support for people passing arguments. 'nargs=?' [1]
looks promising but it has an annoying tendency to swallow a positional
argument following it [2]. Since that is not an option, we have to live
with a new config option, '--use-config-drive' and a '--no-config-drive'
counterpart.
[1] https://docs.python.org/3/library/argparse.html#nargs
[2] https://bugs.python.org/issue9338
Change-Id: If9cce0ad4094cc9cef1c9136b80c3b0f35a82c7a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Story: #2005468
Task: #30547
The switch to using glance from the SDK accidentally used get_image
directly during a server rebuild, when it should have used find_image to
match existing functionality.
Bug introduced in: I36f292fb70c98f6e558f58be55d533d979c47ca7
Change-Id: I2005bd40a1bd6719670c7f7854316b4f9801b140
Story: 2007620
Task: 39643
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
While cold migration and resize are essentially the same operation under
the hood, meaning one could use the 'openstack server resize confirm'
and 'openstack server resize revert' commands instead, there is no
reason the operator needs to know this. Add these flags as syntactic
sugar to help simplify operators lives.
The help texts for both the 'openstack server resize' and 'openstack
server migrate' commands are updated to clarify the relationship between
the two operations.
Change-Id: I0cb6304c794bffaec785add9f7b8cf53ab28cacd
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This patch adds a new parameter ``--availability-zone`` to
``openstack server unshelve`` command. This can help users to specify
an ``availability_zone`` to unshelve a shelve offloaded server from
2.77 microversion.
Depends-On: https://review.opendev.org/679295
Implements: blueprint support-specifying-az-when-restore-shelved-server
Change-Id: Ia431e27c2a17fe16466707cc362532860ecf22df
Pick up newer versions of this library. Thankfully no serious changes
are needed.
Change-Id: I69e523844529fc1c8aa0c1ce764182dbe29cfeb6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This adds a --boot-from-volume option to the server create
command which is used with the --image or --image-property
option and will create a volume-backed server from the
specified image with the specified size. Similar to the
--volume option, the created root volume will not be deleted
when the server is deleted. The --boot-from-volume option
is not allowed with the --volume option since they both create
a block device mapping with boot_index=0.
Change-Id: I88c590361cb232c1df7b5bb010dcea307080d34c
Story: 2006302
Task: 36017
