This change adds a DELETE call on the server-migrations object to cancel
a running live migration of a specific instance.
TO perform the cancellation the virtualization driver needs to support
it, in case that the feature is not supported we return an error.
We allow a cancellation of a migration only if the migration is
running at the moment of the request and if the migration type is equal
to 'live-migration'.
In this change we implement this feature for the libvirt driver.
When the cancellation of a live migration succeeded we rollback the live
migration and we set the state of the Migration object equals to
'cancelled'.
The implementation of this change is based on the work done by the
implementation of the feature called 'force live migration':
https://review.openstack.org/245921
DocImpact
ApiImpact
Implements blueprint: abort-live-migration
Change-Id: I1ff861e54997a069894b542bd764ac3ef1b3dbb2
This patch does two things:
1. Add two APIs /servers/migrations:index/show for server migrations.
Two new novaclient commands server-migration-list and
server-migration-show will also be added.
ref: I071198fa9ba0699383bdebf4fab54714a435e6c3
2. Add ref link for /os-migrations
The old top-level resource `/os-migrations` won't be extended anymore.
It is deprecated.
Adding migration_type for it, also add ref link to
/servers/{uuid}/migrations/{id} for it when the migration is an
in progress migration.
Partially implements blueprint live-migration-progress-report
Change-Id: Ia92ecbe3c99082e3a34adf4fd29041b1a95ef21e
Co-authored-by: ShaoHe Feng <shaohe.feng@intel.com>
The "os_compute_api:<extension>:discoverable" policies control whether
or not the extension is advertised as being available. By default they
should all be advertised so the policy should make it clear that it's
explicitly allowed.
Change-Id: I8aaeea571165f4052ecd6ad4348673e0f9a187ac
A blank policy is equivalent to a policy that allows everything. In
practice this is probably not what you want, and there is no indication
that the policies were set this way for that reason, except for one
case. It appears to be a matter of copy/paste.
The exception is the policy check for default quota-sets. The default
quota set is not scoped to a project or user so checking for ownership
does not make sense. And since it is the same for every project there's
no reason to require an admin context in order to view it. So it's set
to "@" here to be visible to all.
The rest of the calls end up having ownership verified in the db api by
filtering on project_id, unless it's an admin context. So admin_or_owner
ends up being equivalent to what's in place, but verification happens at
the policy level which is where it should be checked.
Change-Id: I698c8aa54e90fc285a4a6e0a9105e8d1ccb90c8a
/usr/local/{sbin,bin} is a standardised location for admins to install
non-distro executables, and these executables are no less "trustworthy"
than /usr/bin and friends. See neutron and cinder's rootwrap.conf (and
probably others), and typical distro default values for
sudoers/secure_path for extremely similar precedents that all include
/usr/local/*bin.
In particular, some sort of change like this is required for
oslo.privsep to find its "privsep-helper" executable in
devstack (installed into /usr/local/bin via pip). The only open
question (imo) is whether this change is made here in nova (and any
other project that doesn't already have this), or rootwrap.conf is
modified in the same way at "deployment time" by devstack and other
deployment methods. Doing it here means it is far more likely to "just
work" for the common case of installing at least one affected command
into /usr/local.
See I710cf142b834381c00e651cfc062299ae755c33f for some brief discussion
of doing this via devstack, and pointers to earlier neutron, etc
discussion.
Change-Id: I6a0a4b7f952193ce0f4ed2594613188854d36bf1
Common memorycache was replaced by analogous tool
from oslo.cache lib. In-memory cache was replaced
by oslo.cache.dict backend. Memcached was replaced
by dogpile.cache.memcached backend.
Implements blueprint oslo-for-mitaka
Closes-Bug: #1483322
Co-Authored-By: Sergey Nikitin <snikitin@mirantis.com>
Co-Authored-By: Pavel Kholkin <pkholkin@mirantis.com>
Change-Id: I371f7a68e6a6c1c4cd101f61b9ad96c15187a80e
move os_compute_api:servers:discoverable to other
policy defined position to make them easier
to be recognized and used by end user.
Change-Id: I5fc4b55418f187817e81343e9224b731f8eea5e2
This change adds manual knob to force ongoing live migration to
complete. It is implemented as a new server-migrations API.
DocImpact
ApiImpact
Implements: blueprint pause-vm-during-live-migration
Change-Id: I034b4041414a797f65ede52db2963107f2ef7456
ImageCacheManager deletes base image while image backend is copying
image to the instance path leading instance to go in the error state.
Acquired lock before removing image from cache. If libvirt is copying
image to the instance path, image cache manager won't be able to remove
it until libvirt finishes copying image completely.
Closes-Bug: 1256838
Closes-Bug: 1470437
Co-Authored-By: Michael Still <mikal@stillhq.com>
Depends-On: I337ce28e2fc516c91bec61ca3639ebff0029ad49
Change-Id: I376cc951922c338669fdf3f83da83e0d3cea1532
Change I9b649aafba011d537e3fe4eebef7a678ff6733e4 has added a
compute API to trigger crash dump in instance. This patch adds
the REST API to nova. It enables users to trigger crash dump in
an instance through REST API.
Change-Id: I6ed777ff637254b4b79417008f9055dd19fc7405
Implements: blueprint instance-crash-dump
Co-Authored-By: Hironori Shiina <shiina.hironori@jp.fujitsu.com>
Co-Authored-By: Tang Chen <tangchen@cn.fujitsu.com>
When a compute service fails, the power states of the hosted VMs are not
updated. A normal user querying his or her VMs does not get any indication
about the failure. Also there is no indication about maintenance.
This change will expose new attribute host_status to user querying his
VMs. Attribute is only seen if policy allows.
DocImpact: This adds API microversion
Implements blueprint get-valid-server-state
APIImpact
Change-Id: I5abea08bdc27624a7f23a7db8964f8c2a7b0eaa7
It's used to plug/unplug VIF_TYPE_MIDONET vifs on compute nodes.
Closes-Bug: #1533473
Related-Bug: #1235132
Change-Id: Ic8e8b19ec1083d1c9cdab3d17dcaddbe43bb76b4
To create a "nova.conf.sample" file, we use "tox -e genconfig".
This command triggers the generator from "oslo.config" which needs
entry points in "setup.cfg". Right now we have multiple entry points
to "opts.py" files which are going to be consolidated to one single
point of entry "nova/conf/opts.py". Until all config options are
moved to that central place, we would often face merge conflicts
when multiple contributors commit patches to that one "opts.py".
To prevent that, and to make it easier for future config option
moduls in "nova/conf/", the new "nova/conf/opts.py" module collects
the config options in a dynamic way.
Co-Author: EdLeafe <ed@leafe.com>
bp centralize-config-options
Change-Id: I4e5d643cd93bb2822ff59c71669cedf3de7f86fc
The get_lock method in compute/api.py is no longer in use.
Need to remove the get_lock method and the get_lock policy
action from the default policy.json file.
Change-Id: I6a8bb58f749ecb64bd22be1fc8f96beebd75e38b
We stopped talking about /v1.1 nearly 3 years ago, it's in no
documentation. It should not be in our default deployed paste.ini as
it will only confuse folks.
Change-Id: Id695f60e30b14f939973e3610c7750b83a14d0d0
Tempest has already removed the EC2 API tests in:
Ib5e24e19bcba9808a9f49fe7f328668df77fe4f9
We have a review in devstack below that removes EC2
API service by default.
In this review, we are removing support for the really
old EC2 API support in Nova. Anyone who needs EC2 support
should use the new EC2-API project:
http://git.openstack.org/cgit/openstack/ec2-api/
The necessary changes in Tempest and DevStack are
already merged. In a follow on review, will remove
the EC2 specific options, code and tests from Nova.
DocImpact
Change-Id: Id7936be290b6febd18deb4c2db8ea4d678d4d9b1
This commit adds support for create/delete a fp netdevice interface
when a vhostuser port is plug/unplug.
Implements: blueprint libvirt-vif-vhostuser-ovs-lb-fp
Change-Id: I53a182461b38d4cc79dbf9a6031b4953cc1ba089
Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
Use the new oslo.report config option for specifying a
log_dir in which the GMR reports can be generated in.
consolidate the gmr related setup code in config.py
Introduced in oslo.reports change id:
I9ed0191628f2d552acd8130687b636671bc07a3e
Change-Id: Ib5edf65fd33ce86757f7cb1a6546a6f00738c9a3
The word "explicitely" should be spelled as "explicitly".
So it is changed.
(df) Ran spell-check on entire file and fixed a few more
misspellings.
Change-Id: I25d2accc2e0a1aaff71011944a62dadceb508b47
Closes-Bug: #1501202
This adds the CORS support middleware to Nova, allowing a deployer
to optionally configure rules under which a javascript client may
break the single-origin policy and access the API directly.
The paste.ini method of deploying the middleware was
chosen, because it needs to be able to annotate responses created
by keystonemiddleware. If the middleware were explicitly included,
keystone would reject the request before the cross-domain headers
could be annotated, resulting in an error response that was
unreadable by the user agent.
The test suite was expanded, to permit the inclusion of
HTTP headers, and to add the ability to send an OPTIONS request.
OpenStack CrossProject Spec:
http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html
Oslo_Middleware Docs:
http://docs.openstack.org/developer/oslo.middleware/cors.html
OpenStack Cloud Admin Guide:
http://docs.openstack.org/admin-guide-cloud/cross_project_cors.html
bp:nova-cors
Change-Id: Ibc95df0860799ff36f682da7d032d5422b0c39c1
Change Openstack to OpenStack as per
standard and
change "stackforge/ec2-api to
openstack/ec2-api" because ec2-api had
moved to openstack
Change-Id: I59c8524e8de8b80cf13e076967e68f5edf8b507e
In I8d58be7f3cb1bdefc3b783a256c21ed216cdbad7, we added
"compute:delete", "compute:soft_delete" and "compute:force_delete",
So let's remove the older lines that have the an empty "" target.
Change-Id: I239ca596cca4631e311d7afe45de7ffcc60f70b9
Added a LOG.info nova.policy:enforce method to print
what exactly we are testing in our gate jobs (see
I62d8572e36b8ebb5ece218d858679e93ca0f8c7e) and found
these two rules were missing.
Change-Id: I94780b5173a72c93cf3f7e0dabd429f40fcda46f
compute:lock and compute:unlock are currently
used by compute.api function wrap_check_policy
this patch set the default value of them to be
same to os_compute_api:os-lock-server.
DocImpact: make the default policy to identical to v2.1 policy.
UpgradeImpact: old cloud need to care the default value change.
Change-Id: Ib862696bbfb7e979d6198f5ca3155f5d1e7b396b
Instance faults is filled in Instance object, so
compute.api.get_instance_faults() isn't called by
any code logic. Remove it and related test cases.
Change-Id: I6309ab114246bd5a98c238ad6965f9a9bbeee437
Andrea Rosa