There's a need to create a Manila share resource before the upgrade
process and then validate the share after the process is complete.
To achieve this objective, it is essential to incorporate support for
the Manila client, a task that is accomplished through this commit.
Change-Id: I0d520e40a1a491ee864e707d63413d10035b99ca
In case of tripleo setups, Tobiko can be executed from the undercloud or
from a different node (test_host).
In case it is not run from the undercloud, the tobiko-cleanup role has
to be delegated to the undercloud node.
Change-Id: Ic81196dee9735acbd1841baeb25003f96f69d5a2
This patch includes some changes wrt StatelessSecurityGroupFixture:
- a task that cleans up the security groups generated with this fixture
is added to the tobiko-cleanup role
- when TOBIKO_PREVENT_CREATE env variable is set, the security groups
are not created (they should have been created before)
- the lockutils.synchronized decorator is used to avoid that two
security groups with the same name are created concurrently
- neutron.get_security_group(self.name) did not work because that method
does not work with the security group name; it is replaced by
neutron.list_security_groups(name=self.name) instead
Change-Id: I3ab84e138049a27db017630b32d81d290aa5f6cd
This patch removes the tobiko.openstack.neutron._cidr module that was
used to generate CIDRs whenever tobiko was going to create a new subnet.
That method had problems when several tobiko workers running in parallel
tried to create subnets. Collisions happened sometimes, resulting in the
creation of two subnets with a common CIDR that could fail if they were
connected to a common router.
This patch uses the neutron subnet pool feature [1]. When Tobiko creates
a subnet, it will not calculate a free IPv4/IPv6 CIDR, but will
associate that subnet to common Subnet Pools, shared by the different
tests. When the subnet is created, it is neutron responsibiltiy to
allocate a free CIDR for that subnet, based on the created Subnet Pools.
The method that creates the Subnet Pools uses an
@oslo_concurrency.lockutils.synchronized decorator to guarantee that two
Tobiko workers do not create the same Subnet Pool at the same time.
[1] https://docs.openstack.org/neutron/latest/admin/config-subnet-pools.html
Change-Id: I3b09e468310e06f8c4b7d7dbec02e4b2e6f67530
Deletion of heat stacks created by tobiko is not stable enough: the
command hangs forever and some stacks are not successfully deleted
In order to make this task more stable, a timeout is added to the
command and retries are added to the task
Change-Id: I7e1b851d7aa98007917675856cc20bc8fa4085a1
So far, in case that Octavia loadbalancers (both amphora and ovn
providers) have had children (Octavia resources which were associated
to them), they couldn't have been deleted using the current tobiko
cleanup commands.
This patch adds to the cleanup commands the loadbalancer deletion
before the stacks are being deleted.
A seperate BZ (#2060338) was opened against openstack-heat for not
adding the --cascade option when deleting LBs with children.
Workarounds BZ #2060338 until it is fixed.
Change-Id: I58bfd7d1d63c6a028470b895d588d47fd9f0fcc2
When this flag is set, the heat stacks created by tobiko are deleted at
the end of the tobiko infrared execution
Additionally, the images created by tobiko are also removed from glance
Change-Id: I3415a7fd73f02e47cf4a0c3351d90db3f7614fef
