Two-node job was failing because devstack tried to compile the
test_server.go file on controller2.
controller2 doesn't have tempest installed, but octavia-tempest-plugin
was installed. The compilation step was failing and is not necessary
there.
Fix octavia-v2-act-stdby-dsvm-scenario-two-node definition, overrides
were not applied.
Fix the "zuul_copy_output" section.
Move to ML2/OVN backend.
Co-Authored-By: Carlos Goncalves <cgoncalves@redhat.com>
Change-Id: I24976e93e9ea8f7f50c9da014c2627965512893c
A subset of nodepool providers have KVM nested virtualization enabled.
At present, examples are Vexxhost, OVH, FortNebula and Limestone.
We've had a pre-run script for CI to enable KVM when running in one of
those providers. This has some drawbacks:
1. With Zuul v3, DEVSTACK_GATE_LIBVIRT_TYPE is obsoleted in favor of
LIBVIRT_TYPE in devstack_localrc.
2. The list was outdated (e.g. Vexxhost and FortNebula were not in).
3. Some of the nested virt friendly providers have mixed KVM/TCG
servers.
3. Enablement of nested virtualization would require updating of the KVM
providers list in our side.
When LIBVIR_TYPE=KVM, devstack checks if KVM is really available (via
devstack/lib/nova). If it is not, it falls back to qemu (TCG). This
check is available since at least Mitaka.
Also, some provider nodes expose a generic CPU model. Libvirt matches
the named CPU model to the closest from the host. As a result, the
matched one may not include the CPUID parameter which seems to be
required for nested virtualization. This find-by-match (cpu_mode option
in Nova) can be switched "host-passthrough" in which case will cause
libvirt to tell KVM to passthrough the host CPU with no modifications.
The disadvantage of this mode is guests can only be migrated to an
exactly matching host CPU, but we don't need this in CI.
Depends-On: https://review.opendev.org/#/c/703324/
Change-Id: I6c4596aa9cc2d7f7703c5acb54fdaed97756788a
This patch adds a tempest scenario test for active/standby topology.
This scenario takes a similar approach to scenario proposed in Change-Id
Ibcd5552a67cea650edc72bfaa986357267ca2407 with the difference that it
does not rely on amphora stats API. Instead, it uses iptables to log VIP
traffic and make assertions based on logging.
Co-Authored-By: Michael Johnson <johnsomor@gmail.com>
Change-Id: I24a6fc3387166ec6cdbd57a5ca9f63743748ec68
There appears to be a kernel regression that is leading to KVM failures
again. This patch adds limestone to the exclusion list based on job
failures[1].
[1] http://logs.openstack.org/32/600332/3/check/octavia-v1-dsvm-scenario/ \
467a1e6/logs/libvirt/qemu/instance-00000001.txt.gz
Change-Id: I91782536599fc28f2824a5dcc1483be46904ce56
The dsvm scenario jobs was using "octavia-dsvm-base" parent job and
not the required "octavia-dsvm-live-base" job. This patch corrects that.
It also changes the "octavia-v2-dsvm-scenario-centos.7" job name to
"octavia-v2-dsvm-scenario-centos-7" to comply with the naming guideline[1].
The same change is applied to the bionic job, which becomes "-bionic".
It also increases the job timeout for "live" jobs to 9,000 seconds, or
2.5 hours to accomidate tcg gate hosts.
[1] https://docs.openstack.org/infra/manual/ \
drivers.html#consistent-naming-for-jobs-with-zuul-v3
Change-Id: I7aaa86bf0a626cbef17611445d4499969741534d
OVH infra hosts are causing "KVM: entry failed, hardware error 0x0"
failures where instances fail to start (cirros, etc.).
This patch excludes OVH instances from kvm enablement until the issue is
resolved.
Change-Id: I50006cb60deef6943d95c2c04c444dccca94c8b0
A recent kernel update in the nodepool images has resolved the issue
we were seeing with using KVM on some hosting providers.
This patch removes the exclusion for those hosting providers and
allows the Octavia gates to use KVM if it is available on the host.
Change-Id: Ibd726a831db4988ab1820084b2683c38a852ce93
This patch implements the tempest plugin for
for testing load balancer creation in Octavia.
Co-Authored-By: Jude Cross <jcross@godaddy.com>
Co-Authored-By: Lingxian Kong <anlin.kong@gmail.com>
Depends-On: https://review.openstack.org/557856
Change-Id: I57064f8e0834efba8859a780394a1c69851cc917