Remove ACLs for stable/mitaka since that branch is retired.
Remove notifications for stable/mitaka from gerritbot.
Remove now unused job definition.
Remove liberty and mitaka in names for the proposal regex since we have
no such jobs anymore.
Change-Id: I45a666b2bc5c8c4e344f3fe0b582c53459742975
The v3 migration script can handle these just fine - but if we go ahead
and remove them the output can be predominantely shell rather than
script.
Change-Id: I440851a0149e1cc7f8c5c6e8a4e3e0b94088ee82
This will allow configuration of the Cinder LIO job
from the Cinder repository, in order to make adjustments
more easily to the job configuration
This is based on the same idea implemented for Ceph in
Ib3ccd42720ee7f4464567737f0bc1a297c590b74 , except
there is no LIO devstack plugin.
Change-Id: Ie8d00b63bd88e9c842556b7f0abb1239d047614a
The multinode DVR HA job has >90% consistent failure rate and therefore
doesn't bring a lot of value.
Let's replace it by the grenade multinode DVR job which has a
<50% failure rate instead.
Change-Id: I4b762e3a0e47777b8698fc7a5918cecebe0f9418
These jobs are not used in zuul/layout.yaml but defined, remove them:
gate-neutron-vpnaas-dsvm-functional-ubuntu-xenial
gate-oslo.messaging-src-dsvm-full-zmq-default-ubuntu-xenial
gate-tempest-dsvm-networking-odl-carbon-snapshot-v2driver-nv
gate-tempest-dsvm-neutron-src-oslo.versionedobjects-ubuntu-xenial-newton
gate-tempest-dsvm-neutron-src-oslo.versionedobjects-ubuntu-xenial-ocata
periodic-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-master
Remove now unused stable-compat-jobs template and job-group.
Remove now unused
'{pipeline}-tempest-dsvm-neutron-identity-v3-only-full-{node}{suffix}'
job-template.
Change-Id: I572c8700ba1300b8f01d83d33ba6b2993104680e
This job currently online runs on stable/newton today and is failure.
This is because it is attempting to install keystone from
stable/mitake branch, however this branch no longer exists. As a
result, it is just blocking patches to stable/newton on devstack now.
Change-Id: I948ea195ddfaf0854ecbd8c6de1d02ec61813b90
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We have removed the devstack-jobs job group, so rename now
devstack-jobs-xenial to devstack-jobs and remove the obsolete comment.
Change-Id: I54dbdaa97e0018e71cb88558ddb2bbcec917a62c
django_openstack_auth includes this devstack-gate job and relies on
horizon being enabled in devstack. Add a conditional check for this
specific project to the gate job.
Change-Id: I1e4a636bbe74d25ed45921b044298554ed0e8d2f
Since I187e560911f5d5d482eb7959e5174068c4c9a801 ssh validation is
enabled by default in devstack on master (Pike).
The neutron-full-ssh test was introduced as a test to make ssh
validation stable. Now that that goal is achieved, it can be
removed.
Since neutron-full-ssh was the only job running with file injection
enabled, enabling it now in the standard neutron-full job.
Change-Id: I568c56dbcb62ec541661364c142eff2397e3eed7
There are two lvm-multibackend jobs really:
1. The multinode one runs slow scenario tests which will
test volume retype with a volume attached to a server for
swap volume operations.
2. The single node one runs only volume API mulitbackend
tests, so retype but without the volume attached to an instance.
This change adds a comment explaining what the multinode lvm
multibackend job does and adds it to Cinder's experimental queue.
It also removes the single-node job from Nova's experimental queue
since Nova was running both jobs in the experimental queue but Nova
is only going to care about the slow scenario test where an instance
is involved with the volume retype scenario.
Change-Id: Ibd642084be27bfce55e9939a09835c034e41a1bf
This enables tlsproxy in the python35 job so that we can get closer to
enabling that by default in devstack.
Change-Id: I22ba399a64a84c11f58124dd4d999bd2aacf6ae9
Depends-On: Id1369da0d812edcf9b1204e9c567f8bfe77c48b2
Tempest has few volume multibackend tests like
test_volume_migrate_attached.py. Those tests are now marked
as slow tests.
These tests used to run in lvm multibackend experimental job
but not now as these tests became slow tests and this job does
not run slow tests.
- gate-tempest-dsvm-lvm-multibackend-ubuntu-xenial-nv
Now multibackend tests does not run anywhere and scenario multinode
job is place where all the slow scenario tests run.
This commit enables lvm multibackends on scenario multinode job
and rename it accordingly.
Change-Id: I2606c689a33c4402cd81fef32db894b9b139cf78
Increase concurrency to two, and add compute migration tests, so
we can keep them running fine. A multinode environment is the
right place to run migration test.
Change-Id: Ib850dc0f8c73d0cba421777925c0619802fed3cc
{plugin-repo} expands to "openstack/devstack-plugin-ceph" when we only
want the name of the local directory when looking for a configuration
override.
Change-Id: Id9842b444a88b2e17a9dcef6d10ebbbd2d72a85b
The last of the layer4 service tests (for heat) are being removed from
tempest. However, this job is blocking that from happening because tests
have to run for the job to pass. This commit removes the job since
it's not doing anything anymore.
Change-Id: I983de842f1bf84a939cbcda6c65185c694a69949
Needed-By: Ifc2cac575919da4e361eaa3234d7e0f3e2f98d21
Use devstack-gate variable DEVSTACK_PROJECT_FROM_GIT instead of devstack
variable LIBS_FROM_GIT. In this case, we do not need to set PROJECTS
variable and can thus avoid some duplication.
In barbican.yaml: Rework several if conditions into elifs since only one
of these can be true - this makes it easy to see that we do not override
DEVSTACK_PROJECT_FROM_GIT wrongly.
Change-Id: Ib7b187ab9d44d76a007abc23a0feafaab1855030
Change Id2caf9561b361c1d4950856423282535d067e015 for devstack adds all
repositories in DEVSTACK_PROJECT_FROM_GIT to PROJECTS, so no need to add
repos in jobs to PROJECTS if there are in DEVSTACK_PROJECT_FROM_GIT.
This change went through all of jenkins/jobs and removed PROJECTS where
there is direct 1:1 correspondence. For a few files, especially ironic
and freezer, this was not doable.
Change-Id: I4b51e33b9bc0f1cb7948b69abf104e0b57b9ff52
This will allow us to further refine the set of tests to run and we
maintain this configuration within the plugin repository. The
configuration file path is wrapped in a conditional to prevent the job
from failing while the plugin configuration is being tested and refined.
Change-Id: Ib3ccd42720ee7f4464567737f0bc1a297c590b74
Trusty is only used in mitaka jobs and mitaka is end of
life basically, so we can drop these from the nova
experimental queue now.
Remove a job definition that is unused now.
Change-Id: I800998f4110a914233dca376a52fdb97f40872d1
This reverts commit 94734cf845.
This landed before the script was merged which removed the mandatory arg
'--regex' while running the tempest tox command.
Results to ceph job failing everywhere.
Once we are ready with script then we should change the job accordingly.
Change-Id: Ic505389483286347f00e8a9e3e0dc1e720b0981d
Ceph jobs are failing because they attempt to clone the devstack ceph
plugin repo outside of devstack-gate. Fix this by adding the plugin repo
back into the PROJECTS list.
Change-Id: I8e298935e61eaca54eaa710047a2dc46fd82b86b
Now that liberty is end of life, stable/mitaka is the only
branch that can run on ubuntu trusty nodes and we want to
pair down our list of available jobs a bit. This patch removes
some trusty-based jobs from the nova experimental queue with the
understanding that nova doesn't really need to run these against
stable/mitaka changes, generally either because they don't provide
good coverage or are necessary for the types of fixes that get
backported to stable/mitaka, or just because they probably don't work
on mitaka anyway.
Change-Id: I8a3ee9ed3df1ed08f987b7ae5ea4bed1ed32e758
In the prior change [1] PROJECTS was updated for
the wrong job, which causes the dsvm-full-lio job
to fail.
[1] https://review.openstack.org/#/c/449799/
Change-Id: Iee8f4f3f7d946c1adfb71ed4e65cd3a14061b7b8
The goal here is to test volume encryption
using Barbican rather than ConfKeyManager.
Move LIO's local_conf to new format.
Change-Id: I1fee50672ac79f856e169ac3ef3e0fd41c956bd0
The tempest scenario job uses the multinode topology, but it's setup
to use a ubuntu-xenial node, which is a single node topology.
Using ubuntu-xenial-2-node as a node type instead.
Change-Id: Ib122063b3e91a82eb9f63febf9fd307326d13160
In [1] the VNC related errors for
gate-tempest-dsvm-multinode-full-ubuntu-xenial-nv were fixed, but we are
still seeing them in
gate-tempest-dsvm-neutron-dvr-*multinode-full-ubuntu-xenial-nv jobs, so
add the same local_conf settings there.
[1] https://review.openstack.org/444164
Change-Id: I9d78e7f96af09a1983b90eb5f7fa721d42c3605b
We can clean up unnecessary job defs for d-g unittests and get better
logging by using the standard tox builder for this. This isn't in the
same change as the previous one as its a bit larger and may need better
review.
Change-Id: Ic9273c1b347abc85809bc910ab5e85c0a30389ee
It turns out that our run-tox.sh scripts can't handle multiple tox envs
in the envlist. Instead of running d-g unittests under py2 and py3 in
the same job using multiple env list entries just run two jobs.
A future improvement to run tox to handle multiple envs in the envlist
would be nice but that affects far more jobs so this is simpler for now.
Change-Id: I00a7a71133f6bd8f2ec45c4a904892979f01ad36
Commit https://github.com/openstack/tempest/commit/1f87a5611a added a new
tempest test "compute.servers.test_novnc.NoVNCConsoleTestJSON.test_novnc".
This test fails intermittently in multinode jobs. The test revealed that
the multinode test job has a wrong configuration.
The compute node ("subnode") in the multinode tests has a wrong value for
the config options:
* [vnc].vncserver_proxyclient_address
* [vnc].vncserver_listen
The defaults of these config options are "127.0.0.1", which makes sense in
an all-in-one test setup, but it should be the IP address of the compute node
in an multinode setup.
As the multinode test job uses a controller node (*with* compute services)
+ compute node, this also explains why this fails intermittently. The test
passes if the instance gets scheduled onto the controller node (*with*
compute service) and fails if the instance gets scheduled onto the compute
node ("subnode").
As the tempest tests and the novnc-proxy server are co-located on the
controller node, having "127.0.0.1" for "[vnc].novncproxy_base_url" is
fine(-ish). In a real-world setup this should be the IP address of the
node, where the novnc-proxy service is running (typically the controller).
The flow of commands is this:
* nova-api ask nova-compute for a valid VNC connection info object
(with an "access_url")
* nova-consoleauth authorizes the connection info with a token
* nova-api returns the access_url + token
* a vnc client uses the access_url + token to establish a connection
* that access_url points to the nova-novncproxy service
* the nova-novncproxy service uses the token to get the connection info
object from nova-consoleauth
* that connection info object contains the IP address of the compute node
where the instance lives
* nova-novncproxy establishes a connection to the compute node
* the instance listens on the IP address of the compute node for incoming
traffic
The "access_url" is derived from the config option (confusingly named)
vnc.novncproxy_base_url and the IP address the nova-novncproxy
uses is derived from the config option vnc.vncserver_proxyclient_address
The important code pieces are:
* nova-api:
324768752f/nova/compute/api.py (L3419-L3430)
* nova-compute manager:
63805735c2/nova/compute/manager.py (L4543-L4571)
* The console class:
50c8f93e51/nova/console/type.py (L16-L28)
* Libvirt driver:
5f16ce546f/nova/virt/libvirt/driver.py (L2800-L2817)
Co-Authored-By: Michelle Mandel <mmandel@us.ibm.com>
Change-Id: Idfc33d838d1d83793b7d9e4bc75acd4b14e622ab
Closes-Bug: 1669468
Monty Taylor