As a failsave the migration code can create a backup of
the controllers to use in case that the migration fails
and leaves the environment on a unusable state.
The revert plan has two stages:
1- Backup stage: included on the current ovn-migration.yml.
Can be configured using the env variable CREATE_BACKUP
(True by default). This stage will run the new ansible
role, recovery-backup.
It will store the backup on `/ctl_plane_backup` on the host
where the BACKUP_MIGRATION_IP belongs to (can be modified by
modifing the env var).
In order to restore the controllers, boot them using the iso created
by ReaR (stored in /ctl_plane_backup) and perform `automatic recover`
2- Revert stage: this stage has its own ansible playbook (revert.yml)
This playbook will clean the environment from all the OVN ressources
that could had been created (breaking the data plane connectivity)
to leave the environment in a stage where an overcloud deploy with
the OVS templates can be run.
Note: If the user creates new resources after running the backup stage
and then performs the recovery of the controllers, those resources will
be lost.
Change-Id: I7093f6a5f282b06fb2267cf2c88c533c1eae685d
The second tripleo-update call was there only to update back integration
bridge variable. However the action did the whole deploy for all nodes
in the environment, which can take hours to finish. This patch relies on
other patch in THT that sets br-int as default value. This way once
ovn-extras.yml is not used and the integration bridge is not overriden,
we no longer need to update tripleo about the value so it's safe to
remove the second call.
Depends-On: https://review.opendev.org/c/openstack/tripleo-heat-templates/+/847402
Change-Id: I7455852898bb6e9698ecf5261d4401bc5077c506
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
There was a code that worked around a bug in openvswitch. The bug was
fixed in openvswitch 2.13 and we no longer use that version. It's safe
to be removed now.
Change-Id: I8d0e1dac4f6a6d201e29863cc76db3f1ff8595ae
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
IPv4 and IPv6 have different utility in iptables. This patch adds use of
ip6tables the same way as previously used iptables.
Change-Id: I1e8ef2749ac5705563e539a5e9f02c63347b5dbe
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
After migration there is one side of patch port on the integration
bridge. It has no impact on functionality but it's better to remove it.
Change-Id: Icfa2d94e123268679cf152e00e2e3d45162f10b1
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Previously the migration playbook continued even if tripleo deploy
failed which damaged the environment even more. This patch will make the
task fail if deploy fails too. There are also other commands which
return code was ignored.
Change-Id: Ib27fa676e126503eacb97b24e95aa7cd2982adab
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
On OSP17 there are some ml2 ovs services that are not
present on some computes eventhought is defined on the
ansible service facts.
This patch will ensure that only those services that are
actually running will be stopped.
Change-Id: I94f0832d09d263837262ada109a567e864915a1a
Before this patch, when migrating from ML2/OVS to ML2/OVN, we
removed the VIF details that are not used by OVN. However, this
changes how the VIFs are plugged if the hybrid iptables firewall
was used.
In order to not break the migration, we want to keep whatever
plugging was used in ML2/OVS. For this reason, this patch is
leaving the VIF details untouched.
The consequence is that, after migration, whatever workloads
used the hybrid plugging will remain like that. Newly created
VIFs will be plugged to the OVS bridge directly. As a result,
the migration to OVN won't require moving to the OVS firewall
first while in ML2/OVS.
This patch is also removing the constraint that prevented the
migration if the hybrid firewall was used.
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
Change-Id: Iad4fae7af54cc502ac0ba02a911cdd4fefa13535
[1] Updated the migration script to check for config-download
directory instead of stack, but missed update the Error
message.
check_stack function is renamed to check_source_inventory
as now it only checks for source inventory instead of heat
stack.
If source inventory file doesn't exist the script
will report Error message and exit.
This is follow up of [1].
[1] https://review.opendev.org/c/openstack/neutron/+/834925
Related-Bug: #1966099
Change-Id: I2416fba50fc495da4d59a3f335f33d831ca6e91d
This Will help in troubleshooting failures related to high
memory or cpu usage.
Related-Bug: #1966394
Change-Id: I74b0d53bfc54b71d3e8b2d46739a944e5f5a6b6f
The validation is intended mostly for tests and don't make much sense
when running the migration in production because likely there are
already running workloads. This patch changes the default to False so
migration validation must be explicitly asked for.
Change-Id: I5470f61a5e0b55bf682526208c3f57dc0ca6ffd5
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
tripleo-ansible-inventory stopped working in Wallaby. However, TripleO
now stores the needed ansible-inventory on the undercloud filesystem.
This patch switches from dynamic generation of the Ansible inventory to
use of the already existing inventory file. Fortunately, the format of
the file remained the same as the generated one, so no other changes in
parsing are required.
Closes-Bug: #1966099
Change-Id: I3bdf878617fbe962d56ebb66d59ae7edeb9b7c38
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
It's a common practice to have /tmp/ mounted separately with noexec
option. This effectively means no scripts can be executed from the
filesystem mounted to /tmp.
This patch explicitly calls sh binary to execute scripts from /tmp and
removes the executable flag from the scripts.
Closes-Bug: #1965183
Change-Id: I2f9cd67979a8a75848fcdd7a8c3bb56dd3590473
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
During the clone-br-int the interfaces sg- (SNAT)
and the interfaces fg- (FIP) are cloned. But this
is not necessary, since this kind of interfaces
are useless on OVN (OVN uses OpenFlow).
Change-Id: I3cd74d1d4fca9add50b0700a82b8e8a16140f085
Port status, server status and server console log output are printed
when the create-resources.sh script fails during the OVN migration
Example: OVN migration fails because SSH connection is not possible,
after ping successfully replied - probably a metadata issue and having
the console logs could help to identify it
Change-Id: I83e55203907526caf44ba34cd38241eccf70adb3
After stopping and deleting the services if this role is runned
again it could fail bc systemd has still some ovs services loaded
(eventhough the service is stopped) this will cause that ansible
will try to delete again and fail while trying to disable and
delete the service.
Change-Id: If51d7f25375768f8c60492c84d84e91d91886025
Following fixes are done in the script:-
- Use openstack_citest as db user as done in CI[1] as
with root as db user it fails configure it.
- Use MYSQL_USER var instead of hardcoded root user
- Fix Syntax Error in CREATE USER psql command by using
quotes for DATABASE_PASSWORD
- Swith to root user for running psql command as without
it, it asks for stack user password which is not configured,
same is done in devstack[2].
- Create variable DATABASE_NAME for database name and use
at all required places.
[1] https://review.opendev.org/c/openstack/neutron/+/814009/
[2] https://opendev.org/openstack/devstack/src/branch/master/lib/databases/postgresql#L90
Change-Id: Ieb523e3afdf69fff87ea9062ed857c37a8d56f5c
While migrating from OVS to OVN one of the steps of the migration
is clean all the OVS trunk ports, this will fail if the environment
does not have any trunk ports configured.
This will do a comprovation in order to know if it's necessary
to clean them or not.
Also, since this playbook it will only clean the ovn interfaces
it is not necessary to stop the whole migration. If any error
occured while deleting any ovs interface a message will be
printed so the user can take action if necessary.
Change-Id: I6ec0b392b13daa9f64e051fb12b4b97a6c0a1730
This is basically revert of the [1] which was revert of the [2]
but now it should not break our CI jobs.
In the configure_for_func_testing script openvswitch is installed
from source. We need to set proper flag (Q_BUILD_OVS_FROM_GIT) which
is used in Devstack to tell Devstack to install it from source and
not from packages.
This patch also removes flag BUILD_OVS_FROM_SOURCE from the
configure_for_func_testing file as it was only used in that file
and was actually duplicating the Q_BUILD_OVS_FROM_GIT option used also
in Devstack.
[1] https://review.opendev.org/c/openstack/neutron/+/824750
[2] https://review.opendev.org/c/openstack/neutron/+/824750
Change-Id: I35715a047d23ed87312afd294cc898de7c164583
This reverts commit 391726bd4c0302ca3ce27f5de8e39ee4c6d91457.
Reason for revert: This patch is breaking CI testing, functional jobs. Variable
"BUILD_OVS_FROM_SOURCE" should be kept.
From a working CI job:
/home/zuul/src/opendev.org/openstack/neutron/tools/configure_for_func_testing.sh:_install_base_deps:106 : [[ True == \T\r\u\e ]]
From a now broken CI job:
/home/zuul/src/opendev.org/openstack/neutron/tools/configure_for_func_testing.sh:_install_base_deps:106 : [[ False == \T\r\u\e ]]
"BUILD_OVS_FROM_SOURCE: True" in the "neutron-functional" job definition.
Closes-Bug: #1957936
Change-Id: I564358c64c8ea7ae6039e9f8e6c0e90655fbb8eb
It was accepting 3 arguments where first one was "build_modules".
It wasn't used anywhere in that function so it was removed from
it.
This patch reflects that Devstack change in the Neutron's functional
tests script too.
Closes-Bug: #1957887
Depends-On: https://review.opendev.org/c/openstack/devstack/+/822717
Change-Id: Id8302bf23f48b227d05f1ec2a7136935b7b1c2fb
In the configure_for_func_testing script openvswitch is installed
from source. We need to set proper flag (Q_BUILD_OVS_FROM_GIT) which
is used in Devstack to tell Devstack to install it from source and
not from packages.
This patch also removes flag BUILD_OVS_FROM_SOURCE from the
configure_for_func_testing file as it was only used in that file
and was actually duplicating the Q_BUILD_OVS_FROM_GIT option used also
in Devstack.
Change-Id: I09c79d0e9700cc2bfdf71e5314ea660de75ac1d3
Prevent the OVS to OVN migration if any node has the OVS agent
firewall set to "iptables_hybrid". If present, the migration will
exit. This check is implemented in the OVN migration script for
TripleO environments.
Closes-Bug: #1951272
Change-Id: I55f25f56f87bfa2a5e330cdf4c1087e8d4082b29
This change is to include missing OvS DPDK nodes also as part of
ovn-controllers group in hosts_for_migration file.
Change-Id: Ic0727ffdbd1f60574b6d5397177a58172cbd60f0
It's not needed at all so if we avoid installation, especially from
sources, it may save us few minutes of the job's execution time.
It may also save some resources on the node.
To save a bit more time in the fullstack job's execution this patch also
disables compilation of the OVS from source in that job. We can use OVS
installed from packages provided by the distro instead.
Change-Id: Ic4b6740671e51f0d306967013e3d500f4d0cd6a5
This patch adds definition of the functional and fullstack jobs
with enabled support for FIPS [1].
Jobs are based on the Centos 8 stream as this disto allows to enable
FIPS support.
Jobs are added to the experimental queue for now.
This patch also makes some changes in the bindep and
configure_functional_tests role to make functional/fullstack tests
working on the Centos.
[1] https://csrc.nist.gov/publications/detail/fips/140/3/final
Co-Authored-By: Ade Lee <alee@redhat.com>
Change-Id: I582495826155740ad2660ee2a8717696b0393d26
- Telco usecases requires a flavor which has to contain "extra_specs"
to boot a dpdk instance.
Add the "FLAVOR_NAME" parameter to override the use of the default
flavor used during migration flow.
- Modify the hardcoded server user name (cirros) to use the
"SERVER_USER_NAME" environment variable.
Change-Id: I3d50526d3192cafb673092bc8b22da6c48454434
Currently workload VMs start before subnet is connected to router.
When DVR is enabled this causes sometimes that one of the VMs is not
able to get metadata.
Closes bug: #1947547
Change-Id: Ifd686d7ff452abd1226fbbc97f499e05102e4596