This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I74e78bc8a7c9ad8c0c41b6693bd642f182214ca6
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I0d7b94ec4aa23791dc48d6e92507364a4897a57a
Story: #2002586
Task: #24310
Normally, OpenStack Release Bot propose this change [1].
However, masakari did not get that proposal. This is maybe,
when pike released, masakari was not an official project.
This patch propose stable/pike cap for upper-constraints.txt
[1] https://review.openstack.org/#/c/492981/
Needed-By: I2903653a13313b0eee7ba30705a453064b1e4991
Change-Id: Ifc30770a20e819c531d5e85ff3bc8e9be088166d
Currently on master error instances are evacuated from failed
compute host and stopped at the destination host after evacuation.
Some operators may not want to evacuate error instances in some
cases like below:
If user is running 1ACT/n SBY application on instances, launching
error instances will cause unexpected effect.
This patch adds a new config option 'ignore_instances_in_error_state'
under [host_failure] section which makes the recovery of error
instances configurable. If this config option set to True, masakari
will skip the recovery of error instances otherwise it will evacuate
error instances from a failed source compute node along with other
instances. The default value for this config option is set to False.
Change-Id: I24f8282357f28544fd1b56f270da22c7329a9f3d
Domain name is needed when using keystone v3 to create keystoneauth
session[1], otherwise the following error will be raised:
InvalidInput: Invalid input received: Expecting to find domain in
project - the server could not comply with the request since it is
either malformed or otherwise incorrect
[1]: https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#v3-identity-plugins
Change-Id: I557a7107b51ae4ffab15d045a4be6e3ed1940bd8
Closes-bug: #1710570
As of now host failure workflow was evacuating instances which were
having vm_state as active, stopped, error and resize. It was ignoring
other vm_states such as shelved, rescued, paused and suspended. Made
provision to evacuate instances which are having vm_states such as
shelved, rescued, paused and suspended by changing its vm_state to
error and after evacuating those instances will be stopped.
NOTE:
On master if the instance is in error or resized state then after
recovery it was becoming active. With this patch error instances
will be stopped and then set to error after recovery. For resized
instance if it's previous power_state is 4(SHUTDOWN) then we can
say that before failure the instance was is stopped state and then
it was resized so masakari will stop that instance to maintain
consistency of instance states as the instance was not fully
resized(resize operation was not confirmed). Resized instance which
was in active state before failure will become active again after
recovery.
Closes-Bug: #1693731
Closes-Bug: #1692435
Closes-Bug: #1690995
Closes-Bug: #1690768
Change-Id: I134e8b6ee7315935bd8ce418ef6241be0b9450b3
In newer hacking version 0.12.0 [1], we can enable some of the
non-default hacking rules (one by one), which are disabled by
default. The enabled rules are the following:
* [H106] Don’t put vim configuration in source files (off by default).
* [H203] Use assertIs(Not)None to check for None (off by default).
* [H904] Delay string interpolations at logging calls (off by default).
Enabled these hacking rules by adding them in the list of
'enable-extensions' in tox.ini [flake8] section. Removed the local
implementation of those hacking rules from hacking/checks.py.
The test-requirements.txt is already updated to use the newer
hacking version 0.12.0 with this commit:
cc44a33f3d
[1] See "Enabling off-by-default checks" section:
https://pypi.python.org/pypi/hacking/0.12.0
Change-Id: Ieccd5a84ebd80ba3313016c9caeb036eaa37769b
Currently masakari delete's the host which doesn't belong to the
segment requested in the 'host delete' API's request URL because
host was not getting filtered on the basis of failover_segment_id.
Filtered the host based on 'failover_segment_id'. Added a new
exception 'HostNotFoundUnderFailoverSegment' which will be raised
from db API 'host_get_by_uuid' if the host is not found under the
requested failover_segment. This exception is not caught at API
controller layer as it is a subclass of 'HostNotFound' which is
already caught in controller.
Closes-Bug: #1697629
Change-Id: I3d3e8cffa2f8ea443ccd13b1db61fda55bc07a0d
Giving provision to operators to configure RPC topic for
masakari-engine service can lead to some errors pointed by the
bug: 1643834. So there is no need to let operators choose the RPC
topic for engine service. It's best to deprecate and remove this
option as it's really easy to break masakari by using this option,
and there is little gain for deployers in changing this option.
Change-Id: Ie8e55762201cbf69f90838217098860ded51a307
This patch adds the global_request_id to the constructor for nova
client, which will pass the global_request_id into nova services
on all API calls. Supporting global_request_id makes debugging [1]
easier when request touches many services in cloud. The masakari
request-id will be sent to nova in the request header like below and
it will be available with context.global_id:
-H "X-OpenStack-Request-ID: req-1a9b7b24-02ed-4400-bcc3-cc1bcbb59147"
Masakari is already using newer python-novacliant which supports
global_request_id [2].
This patch also fixes the below debug log message which gets emitted
when any argument gets dropped while creating request context:
"Arguments dropped when creating context: {u'global_request_id': None}"
As decided earlier while fixing the issue [3] this patch adds the
'global_request_id' to the base RequestContext hence removes the
earlier debug log message.
[1] I65de8261746b25d45e105394f4eeb95b9cb3bd42
[2] I5b247f75edeea9da50fe524eadf5f9a2c626d665
[3] d4dd11d7bd
Change-Id: I2139976f6774b10518c7455a9af1b32b1e7b3e7d
Starting since version 2.14, Nova automatically detects whether the
server data is on shared storage or not.
Removed 'on_shared_storage' parameter from nova evacuate call and
bumped nova api version from 2.9 to 2.14 so that shared storage
deployment can be detected by nova. Also added a related note in
README.rst to point out. Operators should configure shared storage
to use maskari otherwise instance data will be lost after evacuation.
Change-Id: I0b0581a5c84143fc91c9fc6e2c440096013c7438
Removed following methods as these methods are not called from anywhere
in the entire code:
* is_user_context
* require_admin_context
* require_context
* authorize_project_context
* authorize_user_context
'is_user_context' method [1] was getting used to check whether the
requested context is of normal user or not. Masakari doesn't allow
normal user to call any API so the code was unreachable. Moreover
masakari don't have any sqlalchemy model having 'project_id' as it's
attribute. So it is safe to remove this code.
[1] https://github.com/openstack/masakari/blob/master/masakari/db/sqlalchemy/api.py#L131-L136
Change-Id: I60f68cbdd80dbce9d3ea95441cf1926ebec1cc8c
The gating on python 3.4 is restricted to <= Mitaka. This is due to
the change from Ubuntu Trusty to Xenial, where only python3.5 is
available. There is no need to continue to keep these settings.
Change-Id: Ieecf7342152cc813ec3585a3b1873ac0dc13d804
Masakari should use ostestr instead of testr. ostestr is more
powerful and provide much prettier output than testr. Other
projects like cinder, nova, glance, neutron etc already uses
the ostestr wrapper.
Using ostestr shows each tests execution separately because of
which it has shown errors related to "KeyError" in existing test
cases. The error looks like below:
"Exception in string format operation: KeyError: u'id'"
This happens if we don't pass keyword argument like "id" to
exception which we expect to be raised from test through
side_effect [1]. This doesn't lead to test failure but it
appears in test logs. This patch fixes such issues by passing
expected keyword arguments to exceptions.
[1] https://github.com/openstack/masakari/blob/master/masakari/tests/unit/api/openstack/ha/test_hosts.py#L364
Change-Id: I91603ea3dcf35fd20a00dcf477b93d612edca362
Masakari can face a race condition where after evacuation of an
instance to other host user might perform some actions on that
instance which gives wrong instance vm_state to ConfirmEvacuationTask
that results into notification failure.
To fix this issue this patch proposes to lock the instance before
evacuation till its confirmation so that any normal user will not
be able to perform any actions on it. To achieve this the
ConfirmEvacuationTask is completly removed and the confirmation is
done in the EvacuateInstancesTask itself by per instance.
Evacuating an instance and confirming it's evacuation immediately
can reduce the performance so this patch uses the
eventlet.greenpool.GreenPool which executes the complete evacuation
and confirmation of an instance in a separate thread.
To check if the server is already locked or not upgraded the
novaclient's NOVA_API_VERSION from 2.1 to 2.9 as the 'locked'
property is available in nova api_version 2.9 and above.
This patch introduces a new config option
'host_failure_recovery_threads' which will be the number of threads
to be used for evacuating and confirming the instances evacuation.
The default value for this config option is 3.
Closes-Bug: #1693728
Change-Id: Ib5145878633fd424bca5bcbd5cfed13d20362f94
masakari-engine considers reserved_hosts which are under maintenance
for host failure recovery when recovery_method is reserved_host,
auto_priority or rh_priority and passes it to workflow for processing.
If the reserved_host is under maintenance then it should not be used
for evacuating the instances for host_failure recovery.
This patch excludes reserved_hosts which are on maintenance for
host_failure recovery by filtering host_list with
'on_maintenance'=False.
Closes-Bug: #1697902
Change-Id: Ie6beff110d03b67d6f5d8694603816c0db017660
Remove the use of identity admin endpoint.
The following patch removed the use of identity admin endpoint from devstack.
Try to remove /identity_admin
https://review.openstack.org/#/c/458226/
So this patch removes the use of identity admin endpoint from masakari
in accordance with the above patch.
Change-Id: I809c6323b68a97095dc904c65627535083ad08cc
Patch: I334da33385b5d6a387824056a5ba6aa982759314 released a new
version of oslo.context which includes the change to add global
request_id to context: I1521188ae627fa2e7d35aa2ffffbcb620c527765.
This patch fixes the failing test cases by adding global_request_id
to context in tests assertion.
Reference to failing logs: http://logs.openstack.org/08/462108/6/check/gate-masakari-python27-ubuntu-xenial/210acc8/
Change-Id: I6e8fe2b3963f4ffdc751c241f03bd47d230f2a98
Fixed os_privileged_user_auth_url "PROTOCOL://HOST/identity_admin"
to "PROTOCOL://HOST/identity".
Current devstack keystone service endpoint url is "PROTOCOL://HOST/identity".
So this patch fixes it.
Change-Id: I2700d541b8c72806e814d10d229032fabde2b38e
If masakari receives instance failure notification it fails to
recover that instance if it is in 'paused' or 'rescued' state.
As a recovery action masakari-engine gives call to nova to stop
the instance but as nova doesn't allow this it returns 409 which
result into instance recovery failure and masakari marks that
notification status as "error".
This can be solved by maintaning consistency between the vm_state
before and after recovery but it requires to start the instance
again to gain the qemu process of an instance back alive which
might change the internal state of the instance which results into
inconsistency between instance state before and after recovery.
So as a solution this patch proposes to ignore the instance recovery
and logs a warning if the instance is in 'paused' or 'rescued' state.
Closes-Bug: #1663513
Change-Id: Id1cce45aad253527bedb58ab32f3d89637e02582
DDT can ease up error tracing and auto generates tests on
basis of different input data.
Reduce test code data by using DDT for segments, hosts, and
notifications.
Co-author: Dinesh Bhor <dinesh.bhor@nttdata.com>
Change-Id: Ie3ce3316c6e2fc3f98df3a51db59ca7f1f1625b8
This patch adds support of 'auto_priority' and 'rh_priority'
recovery_methods in case of host failure recovery.
Instances will be recovered on the basis of recovery_method set
by operator for the respective failed_host's failover_segment.
Implements: blueprint implement-recovery-methods
Change-Id: Ib01ad624f5931f177e4e838494ea772449a35b70
OpenDev Sysadmins