Commit Graph

12 Commits

Author SHA1 Message Date
Bence Romsics
5e0a5d41c7 Rally task definition for port binding scenario
Change-Id: I112e477f95958c6235dbc42da06ebc45b236e8f6
Depends-On: https://review.opendev.org/662781
Partial-Bug: #1833674
2019-07-08 13:25:46 +02:00
Bence Romsics
7be9c10679 Allow VM booting rally scenarios to time out
Not long ago we enabled a rally scenario booting VMs in the neutron gate
so we can collect osprofiler reports about it. The rally scenario we
re-used was only triggered by changes in the rally-openstack repo so I
could not collect data about its failure rate. Now that it's running
frequently in the neutron gate this scenario actually seems to be quite
unstable (usually timing out while waiting for the VM to get to ACTIVE):

http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:\"rally.exceptions.TimeoutException: Rally tired waiting\" AND build_name:\"neutron-rally-task\" AND voting:1&from=864000s

Since we only want to run this scenario for the osprofiler report
we can get rid of the gate instability by allowing a 100% failure rate
in the scenario SLA.

Change-Id: Ied354e8242274c8eeb26909e29afbe6d41662bfc
Related-Change: https://review.opendev.org/662804
2019-06-17 13:59:24 +02:00
Bence Romsics
ccef17605d Run nova's VM boot rally scenario in the neutron gate
As discussed on the neutron_performance meeting [1] we'd like to run
a rally scenario in the neutron gate that boots a vm. Combined with
Slawek's work to integrate osprofiler with rally [2] we should start
to get some insight into neutron's vif plugging performance even if
that's not something directly exposed and measurable through the API.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/latest.log.html#t2019-06-03T16:12:17
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006769.html

Change-Id: I7e2c19e8cdb62cb85046500f862e8dbd42306225
2019-06-06 10:56:34 +02:00
Zuul
9492d40bfe Merge "rally-jobs: Add FloatingIP workloads: assoc/dissoc" 2019-03-01 21:24:43 +00:00
Zuul
44a07e8217 Merge "Enhance rally-job for sec group rules to creates multiple rules" 2019-02-16 05:51:46 +00:00
Sai Sindhur Malleni
3c2a23ba94 Remove trunk rally scenario from plugins
Since the trunk scenario is now present in rally-openstack
tree, it is no longer needed in neutron tree.

Change-Id: I27c9f0baed267ca8bd181d34842b9d5cc03ab846
2019-02-13 13:09:33 -05:00
Bence Romsics
031a6e5246 rally-jobs: Add FloatingIP workloads: assoc/dissoc
As discussed on the neutron-performance meeting [1] floating IP operations
should be covered in the neutron gate rally job. As I set out to write
the missing tests I discovered that some of them were already written
by rally folks. For example see [2]. Keep in mind the test code has been
relocated since to the rally-openstack repository. For example see [3].
They were later added to neutron's rally job definition [4].

Here we add a one more scenario to exercise the floating IP operations
left uncovered by the above changes: associate and dissociate.

[1] http://eavesdrop.openstack.org/meetings/neutron_performance/2018/neutron_performance.2018-10-22-16.02.log.html#l-143
[2] https://review.openstack.org/225223
[3] https://github.com/openstack/rally-openstack/blob/4e4bfc5/rally_openstack/scenarios/neutron/network.py
[4] https://review.openstack.org/620952

Change-Id: Id2e27258f2e9a35bb8123854e098d0822458b314
Depends-On: https://review.openstack.org/624036
2019-02-13 09:30:20 +01:00
Sai Sindhur Malleni
8362c0a050 Enhance rally-job for sec group rules to creates multiple rules
This commit makes use of recently merged functionality in rally
to create multiple security group rules per security group and list
them. This will help us identify API performance regressions with
respect to security group rules.

Change-Id: I92ac9785d2403c00b873e68f30062f9796b9ac8b
2019-02-12 14:42:00 -05:00
Sai Sindhur Malleni
a6422ea8f9 Add Security Group scenarios to rally-jobs
This commit adds security group related rally scenarios to CI.

Change-Id: I11fd3a6d30f743dbeea923407bc72753ba488da4
2019-02-01 15:22:18 -05:00
Juha Kosonen
35d89fad1b rally-jobs: Set floating network as a parameter
The option to define the name of floating network enables more
flexibility for using the task file as is.

Change-Id: Icaf9ca6b337a500d3f76521f94244f1932d0e09b
Signed-off-by: Juha Kosonen <juha.kosonen@nokia.com>
2018-12-17 16:31:10 +02:00
Bence Romsics
e294845541 rally-jobs: Add FloatingIP workloads
As discussed on the neutron-performance meeting [1] floating IP
operations should be covered in the neutron gate rally job.
As I set out to write the missing tests I discovered that some of it
was already written by rally folks. For example see [2].
In neutron we only need to add them to the rally job definition.
Keep in mind the test code has been relocated since to the
rally-openstack repository. For example see [3].

[1] http://eavesdrop.openstack.org/meetings/neutron_performance/2018/neutron_performance.2018-10-22-16.02.log.html#l-143
[2] https://review.openstack.org/225223
[3] https://github.com/openstack/rally-openstack/blob/4e4bfc5/rally_openstack/scenarios/neutron/network.py

Change-Id: Icec7011cb293f1c92d968ef60efe7468ea4631fb
2018-11-29 17:10:05 +01:00
Andrey Kurilin
49e3b37e28 [ci][rally] make the job inherit the right parent
Rally team finally added native Zuul V3 jobs (with a bunch of separate
roles and etc) and for simplification of maintainance, it would be nice
to use them.

Change-Id: I755e776a7c24e1bcdf144d7af071a52633aeb94d
2018-05-16 17:05:43 +03:00