Also disabling the nfv devstack jobs. These jobs are failing
after the recent repo restructuring due to failures in the
FM devstack setup. The jobs can be re-enabled in the future
(after the issues are fixed), if there is some value in
doing so.
Change-Id: Ib443edc76ca636c83331945de74d875ffb3592ac
Story: 2004515
Task: 36579
Signed-off-by: Bart Wensley <barton.wensley@windriver.com>
Nova does not support live migration for an instance with a
non-NIC PCI device. Updating the VIM to avoid triggering live
migrations for these instances - the pci_passthrough:alias
extra spec indicates that there is a non-NIC PCI device.
Change-Id: Ieb0d4b4537c9fca8498b4c40af28183494fa03c7
Signed-off-by: Al Bailey <Al.Bailey@windriver.com>
stevedore was treating the string as a list of characters
The code worked, but was littering the logs with warnings
Change-Id: I40f401aab4927e284cb06752977858c4bcecedf0
When the VIM attempts to clear an alarm, but the request to FM
fails, the VIM is leaving the alarm in its internal list of raised
alarms. The next time the VIM's alarm audit runs, it will see that
the alarm is not raised and raise it. The alarm will then be
stuck.
The fix is to always remove the alarm from the list - even if FM
fails to clear the alarm. The VIM's alarm audit will then clear the
alarm because it will find an alarm in FM that is not in the VIM's
alarm list.
Change-Id: I011d17c00364601400cbd770ed31077e364f2c9f
Preventing the creation of an upgrade orchestration strategy from
controller-0, if controller-0 has not yet been upgraded.
Orchestration only works after controller-1 has been upgraded and
made active.
Change-Id: Ic6a8dcf35ddf7d748645837127c3b170dd24c119
When an AIO-SX is locked, the VIM shuts down all the instances.
When the AIO-SX is unlocked, the VIM then starts all the
instances, but does this in parallel. In some configurations, this
causes too much nova/neutron activity, which can cause various
issues and some of the instances may fail to start.
This commit changes the VIM to only start one instance at a time.
Once the instance goes active/running, the VIM will then move on to
the next instance. If an instance fails to start within 60s, we
move on to the next instance anyways. Note that this change only
impacts lock/unlock on AIO-SX - it does not change the behaviour
for starting instances in parallel on compute hosts (e.g. as part
of patch orchestration).
Change-Id: I203d1ac5911e4dae08b8deefbec326cea0a819b5
When an active AIO-DX controller is powered down, maintenance sends
the VIM a host state change to the offline state and then to the
power-off state. The VIM may not attempt to evacuate instances
from the controller right away, because it is waiting for nova to
indicate the hypervisor on the newly active controller is
available. If the VIM doesn't attempt the evacuates until after
the power-off state is reached, the evacuates will not be allowed,
because the VIM only allows evacuates if the host is in the offline
state. The fix is to allow the VIM to evacuate instances if the
host is in either the offline or power-off states.
Change-Id: I436c0fb3107219445694e2aee25e758c3c08080a
Updating the VIM to use version 2.53 (Pike) of the nova API. The VIM
was previously using version 2.38 (Newton). The main changes are:
- Stop using os-hosts (no longer exists). Fortunately we weren't
actually using this code.
- Use new format for os-services (server uuid now required in URL and
body changed).
- The GET servers now returns a flavor in the response (instead of the
flavor uuid). The VIM was previously using the uuid to look up the
flavor in the instance_type table. Now the VIM must access the
flavor information embedded in each instance.
Note that the server notifications from nova still include the flavor
uuid (we need to switch to the newer versioned notifications to get
the flavor). I changed our notification handling to ignore the flavor
uuid as it is no longer of any use to us.
The main reason for this change is to allow flavors to be modified or
deleted even if in use by a running instance. This brings us in line
with upstream behaviour and will allow us to stop modifying this
behaviour in nova.
Change-Id: I65fab6843174d59782aa7366f2e0cc646cebafb7
Signed-off-by: Al Bailey <Al.Bailey@windriver.com>
Bart Wensley