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
Since the trunk scenario is now present in rally-openstack
tree, it is no longer needed in neutron tree.
Change-Id: I27c9f0baed267ca8bd181d34842b9d5cc03ab846
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
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>
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