Add ``openstack server migration list`` to fetch server migrations.
Part of blueprint add-user-id-field-to-the-migrations-table
Change-Id: I15b4a5aca8d0dee59dd293e7b1c7272cdfbeea20
Modified take_action() method for SetFlavor to use
flavor id instead of flavor name when setting description
Closes-Bug: #1844708
Story: #2007781
Task: #40019
Change-Id: If6798c89fef4c9feb4ebb460722b891f5655037d
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>
Rename metadata to property in all aggregate commands
Beef up functional tests to reduce street racing
Change-Id: I4598da73b85a954f3e6a3981db21891b45d9548c
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
With compute API microversion 2.53, nova-compute services
can only be deleted with the ID as a UUID to uniquely identify
the service in a multi-cell deployment. This documents that for
the "compute service delete <service>" argument. The description
of the "compute service list" command is also updated to mention
that the ID can be retrieved as a UUID using 2.53 or greater.
Change-Id: If7d4a27c0aaef588bcd77dd9edddec1e535fbf31
Story: 2005349
Task: 30302
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
The <id> portion of a --block-device-mapping value can be
the resource name or id since the code uses the appropriate
type-specific find_resource utility to lookup the resource
based on the value given.
This change simply fixes the description of <id> to mention
it's name or id rather than just "UUID". My guess is the
description was originally copied from novaclient where id
must be an id since name resolution does not happen in novaclient.
Change-Id: I567f6f6efb3a3b6d387133d21aa81354b2d753bc
The --block-device-mapping option on the server create
command currently only supports booting from volume and
volume snapshot. A common boot-from-volume scenario is
providing an image and letting nova orchestrate the
creation of the image-backed volume and attaching it to
the server.
This adds support for type=image in the --block-device-mapping
option. The volume size is required in this case. Note that
the CLI currently says if type=snapshot that size is also required
but that's technically not true. When booting from a volume
snapshot, the compute API will use the size of the volume snapshot
to create the volume if an explicit size is not provided. For the
purposes of this patch, we need the size anyway for the image
being the block device mapping source type.
Change-Id: I57b3c261d8309f7b9f62a3e91612bce592a887a3
Story: 2006302
Task: 36016
With compute API microversion 2.53 there is a single
PUT /os-services/{service_id} API which takes the service
id as a UUID. Since the openstack compute service set
command only takes --host and --service (binary) to identify
the service, this change checks if 2.53 or greater is being
used and if so, looks up the service by host and binary and
calls the appropriate methods in novaclient.
If the command cannot uniquely identify a compute service
with the given host and binary, an error is raised. A future
change could add an --id option to be used with 2.53+ to
pass the service id (as UUID) directly to avoid the host/binary
filtering.
Change-Id: I868e0868e8eb17e7e34eef3d2d58dceedd29c2b0
Story: 2005349
Task: 30302
These are currently exposed as flags on the 'openstack server resize'
command but they are in fact operation and should be exposed as commands
in their own right.
The old flag-based variants are deprecated for removal in 4.0.
Change-Id: I733796d3bda6c3755a3d3548bbe695abb474a6a0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This simply updates the docs for the compute service set --up
and --down options to mention that --os-compute-api-version 2.11
or greater is required to use those options.
Change-Id: I52891fe36c84d0df3e868ab4f3c8e2357e9ba529
Adds the --host and --hypervisor-hostname options to
``openstack server create`` CLI.
Depends-On: https://review.opendev.org/670558
Change-Id: If188c3d96fa506dbe62ef256418f2f9bca1520c2
Blueprint: add-host-and-hypervisor-hostname-flag-to-create-server
The compute service commands emit a "Binary" in the output but
the --service filter option isn't as clear that it's the binary
(for set it is but not list) nor do the docs give an example
of a binary (typically nova-compute but could be others like
nova-conductor, nova-scheduler, etc). This simply mentions that
the --service option is the binary for "compute service list"
and gives an example value for the option in both list and set
help.
Change-Id: If87fc37352c3a251cc89041723adbe04dedf4f8a
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
This patch adds a new parameter ``--reason`` to ``openstack server lock``
command and ``--locked``, ``unlocked`` filtering parameters to
``openstack server list`` command. This can help users to provide a
reason when locking the server and to filter instances based on their
locked value from 2.73 microversion.
Implements blueprint add-locked-reason
Depends-On: https://review.opendev.org/#/c/661785/
Change-Id: Ib2714f98b24d47e570da8a6c231e765acd2ff595
Currently, doing a cold migration while specifying a target host is not
possible however nova api supports it since version 2.56.
This patch allows passing "--host" when doing a cold migration.
It runs normally if --os-compute-api-version is 2.56 or greater and
returns an error otherwise.
Change-Id: I960109008096ce8bb4e4c8ca6ffb22c33aacd995
Story: 2003325
Task: 24359
The compute API 2.20 microversion allows attaching and detaching
a volume to/from a server with status SHELVED or SHELVED_OFFLOADED.
For OSC this just means the user has to specify the appropriate
minimum microversion to make that work, so this change mentions
that in the "server add volume" and "server remove volume" command
description.
Related to nova blueprint volume-ops-when-shelved
Change-Id: I4824175e5d9e124e3bd9e9a8fd5a89277efc6cff
The 2.21 compute API microversion allows listing instance
action events and getting action event details for a deleted
server (which can be useful for auditing until the deleted
server is purged). As far as OSC is concerned it's just a
matter of specifying --os-compute-api-version 2.21 or higher
when listing events or showing event details, so this change
mentions 2.21 in the description of those commands.
Related to nova blueprint os-instance-actions-read-deleted-instances
Change-Id: If276c794f448b6fa5b0845499f3507a159acab85
Per the discussion at the Train Forum [1] this deprecates
the problematic --live option on the server migrate command
which, depending on the compute API version used, forcefully
bypasses the scheduler and also does not allow you to live
migrate a server and let the scheduler pick a host.
The --live option is replaced here with two new options:
* --live-migration: this simply tells the command you want to
perform a live rather than cold migration; if specified with
--live the --live-migration option takes priority.
* --host: when specified, this will request a target host for
the live migration and will be validated by the scheduler;
if not specified, the scheduler will pick a host. This option
is mutually exclusive with --live.
We can build on the --host option by supporting cold migrations
with a specified host when using compute API version 2.56 or
greater but that will come in a separate change.
If the --live option is ever used we log a warning.
Note there are several related changes for this issue:
- https://review.openstack.org/#/c/628334/
- https://review.openstack.org/#/c/626949/
- https://review.openstack.org/#/c/627801/
- https://review.openstack.org/#/c/589012/
- https://review.openstack.org/#/c/460059/
This change allows us to deprecate the --live option and provide
a replacement which is backward compatible without having to use
something potentially error-prone like nargs='?'.
Closes-Bug: #1411190
[1] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps
Change-Id: I95d3d588e4abeb6848bdccf6915f7b5da40b5d4f
The following were deprecated over two years ago and can now be removed:
* ``ip fixed add|remove`` in favor of ``server add|remove fixed ip``
* ``ip floating add|remove`` in favor of ``server add|remove floating ip``
These are backwards incompatible changes and will require a major
version bump after they are merged.
Change-Id: I10c4d32a3c0b55ad41a02afd3b14249bafcb55a9
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
These tests are showing signs of problems running in parallel
so serialse the create/delete/list/set/unset tests. They all
used two aggregates each anyway...
Change-Id: Iba4b52c179e6914eaeefea1da0f7eaefcdcf1f87
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
This patch adds functionality to configure server's description with:
1 server create
2 server set
3 server unset
4 server rebuild
Change-Id: Ic06d97b29e51828b29d7ac5172645c288e4ada9e
Story: 2002005
Task: 19640
