Files
ec07b343d25e9964db57ef9c3e2a89deeb5ac56e
devstack /tools /fixup_stuff.sh

121 lines
4.3 KiB
Bash
Raw Normal View History

#!/usr/bin/env bash
# **fixup_stuff.sh**
# fixup_stuff.sh
#
# All distro and package specific hacks go in here
# If ``TOP_DIR`` is set we're being sourced rather than running stand-alone
# or in a sub-shell
if [[ -z "$TOP_DIR" ]]; then
set -o errexit
set -o xtrace
# Keep track of the current directory
TOOLS_DIR=$(cd $(dirname "0ドル") && pwd)
TOP_DIR=$(cd $TOOLS_DIR/..; pwd)
# Change dir to top of DevStack
cd $TOP_DIR
# Import common functions
source $TOP_DIR/functions
FILES=$TOP_DIR/files
fi
# Python Packages
# ---------------
function fixup_fedora {
if ! is_fedora; then
return
fi
# Disable selinux to avoid configuring to allow Apache access
# to Horizon files (LP#1175444)
if selinuxenabled; then
sudo setenforce 0
fi
FORCE_FIREWALLD=$(trueorfalse False FORCE_FIREWALLD)
if [[ $FORCE_FIREWALLD == "False" ]]; then
# On Fedora 20 firewalld interacts badly with libvirt and
# slows things down significantly (this issue was fixed in
# later fedoras). There was also an additional issue with
# firewalld hanging after install of libvirt with polkit [1].
# firewalld also causes problems with neturon+ipv6 [2]
#
# Note we do the same as the RDO packages and stop & disable,
# rather than remove. This is because other packages might
# have the dependency [3][4].
#
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1099031
# [2] https://bugs.launchpad.net/neutron/+bug/1455303
# [3] https://github.com/redhat-openstack/openstack-puppet-modules/blob/master/firewall/manifests/linux/redhat.pp
# [4] https://docs.openstack.org/devstack/latest/guides/neutron.html
if is_package_installed firewalld; then
sudo systemctl disable firewalld
# The iptables service files are no longer included by default,
# at least on a baremetal Fedora 21 Server install.
install_package iptables-services
sudo systemctl enable iptables
sudo systemctl stop firewalld
sudo systemctl start iptables
fi
fi
Use the pip installed version of requests with Fedora The upstream version of requests contains a copy of urllib3 and cardet library, common practice in many distros to create symbolic links for these libraries instead of creating a huge package which contains the same library as the distro provides as separate package as well. Now devstack upgrades the urllib3 to incompatible version, but it leaves the requests unchanged because Fedora already has the latest version. The issue does not happens with Ubuntu because it has older requests and devstack updates it as well. The pip installed version contains a bundled urllib3 and the actually installed urllib3 version does not matters. This is not the `usual` distro package overrides pip installed package case. Change-Id: Icfa71368384b0c2e3ff39265b2fa9190b5566b9b Related-Bug: #1476770
2015年09月01日 15:18:57 +02:00
# Since pip10, pip will refuse to uninstall files from packages
# that were created with distutils (rather than more modern
# setuptools). This is because it technically doesn't have a
# manifest of what to remove. However, in most cases, simply
# overwriting works. So this hacks around those packages that
# have been dragged in by some other system dependency
sudo rm -rf /usr/lib64/python3*/site-packages/PyYAML-*.egg-info
# After updating setuptools based on the requirements, the files from the
# python3-setuptools RPM are deleted, it breaks some tools such as semanage
# (used in diskimage-builder) that use the -s flag of the python
# interpreter, enforcing the use of the packages from /usr/lib.
# Importing setuptools/pkg_resources in a such environment fails.
# Enforce the package re-installation to fix those applications.
if is_package_installed python3-setuptools; then
sudo dnf reinstall -y python3-setuptools
fi
# Workaround CentOS 8-stream iputils and systemd Bug
# https://bugzilla.redhat.com/show_bug.cgi?id=2037807
if [[ $os_VENDOR == "CentOSStream" && $os_RELEASE -eq 8 ]]; then
sudo sysctl -w net.ipv4.ping_group_range='0 2147483647'
fi
}
function fixup_ovn_centos {
if [[ $os_VENDOR != "CentOS" ]]; then
return
fi
# OVN packages are part of this release for CentOS
yum_install centos-release-openstack-victoria
}
Revert "Workaround for new pip 20.3 behavior" This reverts commit 7a3a7ce876a37376fe0dca7278e41a4f46867daa and bcd0acf6c0b5d6501e91133c3a937b3fc40f7122 and part of f1ed7c77c50ac28cb58c9f7ed885c6a3e0a75403 which all cap our pip installs. Given the pip ecosystem can often incorporate major changes, tracking upstream at least generally gives us one problem at a time to solve rather than trying to handle version jumps when LTS distros update. The new dependency resolver included some changes that disallow setting URL's like "file:///path/to/project#egg=project" in constraints. Apparently the fact it used to work was an accident of the requires/constraints mechanism; it does make some sense as the URL doesn't really have a version-number that the resolver can put in an ordering graph. The _setup_package_with_constraints_edit function comment highlights what this is trying to do # Updates the constraints from REQUIREMENTS_DIR to reflect the # future installed state of this package. This ensures when we # install this package we get the from source version. In other words; if constraints has "foo==1.2.3" and Zuul has checked out "foo" for testing, we have to make sure pip doesn't choose version 1.2.3 from pypi. It seems like removing the entry from upper-requirements.txt is the important part; adding the URL path to the on-disk version was just something that seemed to work at the time, but isn't really necessary. We will install the package in question which will be the latest version (from Zuul checkout) and without the package in upper-requirements.txt nothing will try and downgrade it. Therefore the solution proposed here is to remove the adding of the URL parts. This allows us to uncap pip and restore testing with the new dependency resolver. Closes-Bug: #1906322 Change-Id: Ib9ba52147199a9d6d0293182d5db50c4a567d677
2021年07月28日 11:19:57 +10:00
function fixup_ubuntu {
if ! is_ubuntu; then
return
fi
# Since pip10, pip will refuse to uninstall files from packages
# that were created with distutils (rather than more modern
# setuptools). This is because it technically doesn't have a
# manifest of what to remove. However, in most cases, simply
# overwriting works. So this hacks around those packages that
# have been dragged in by some other system dependency
sudo rm -rf /usr/lib/python3/dist-packages/PyYAML-*.egg-info
sudo rm -rf /usr/lib/python3/dist-packages/pyasn1_modules-*.egg-info
sudo rm -rf /usr/lib/python3/dist-packages/simplejson-*.egg-info
Revert "Workaround for new pip 20.3 behavior" This reverts commit 7a3a7ce876a37376fe0dca7278e41a4f46867daa and bcd0acf6c0b5d6501e91133c3a937b3fc40f7122 and part of f1ed7c77c50ac28cb58c9f7ed885c6a3e0a75403 which all cap our pip installs. Given the pip ecosystem can often incorporate major changes, tracking upstream at least generally gives us one problem at a time to solve rather than trying to handle version jumps when LTS distros update. The new dependency resolver included some changes that disallow setting URL's like "file:///path/to/project#egg=project" in constraints. Apparently the fact it used to work was an accident of the requires/constraints mechanism; it does make some sense as the URL doesn't really have a version-number that the resolver can put in an ordering graph. The _setup_package_with_constraints_edit function comment highlights what this is trying to do # Updates the constraints from REQUIREMENTS_DIR to reflect the # future installed state of this package. This ensures when we # install this package we get the from source version. In other words; if constraints has "foo==1.2.3" and Zuul has checked out "foo" for testing, we have to make sure pip doesn't choose version 1.2.3 from pypi. It seems like removing the entry from upper-requirements.txt is the important part; adding the URL path to the on-disk version was just something that seemed to work at the time, but isn't really necessary. We will install the package in question which will be the latest version (from Zuul checkout) and without the package in upper-requirements.txt nothing will try and downgrade it. Therefore the solution proposed here is to remove the adding of the URL parts. This allows us to uncap pip and restore testing with the new dependency resolver. Closes-Bug: #1906322 Change-Id: Ib9ba52147199a9d6d0293182d5db50c4a567d677
2021年07月28日 11:19:57 +10:00
}
function fixup_all {
Revert "Workaround for new pip 20.3 behavior" This reverts commit 7a3a7ce876a37376fe0dca7278e41a4f46867daa and bcd0acf6c0b5d6501e91133c3a937b3fc40f7122 and part of f1ed7c77c50ac28cb58c9f7ed885c6a3e0a75403 which all cap our pip installs. Given the pip ecosystem can often incorporate major changes, tracking upstream at least generally gives us one problem at a time to solve rather than trying to handle version jumps when LTS distros update. The new dependency resolver included some changes that disallow setting URL's like "file:///path/to/project#egg=project" in constraints. Apparently the fact it used to work was an accident of the requires/constraints mechanism; it does make some sense as the URL doesn't really have a version-number that the resolver can put in an ordering graph. The _setup_package_with_constraints_edit function comment highlights what this is trying to do # Updates the constraints from REQUIREMENTS_DIR to reflect the # future installed state of this package. This ensures when we # install this package we get the from source version. In other words; if constraints has "foo==1.2.3" and Zuul has checked out "foo" for testing, we have to make sure pip doesn't choose version 1.2.3 from pypi. It seems like removing the entry from upper-requirements.txt is the important part; adding the URL path to the on-disk version was just something that seemed to work at the time, but isn't really necessary. We will install the package in question which will be the latest version (from Zuul checkout) and without the package in upper-requirements.txt nothing will try and downgrade it. Therefore the solution proposed here is to remove the adding of the URL parts. This allows us to uncap pip and restore testing with the new dependency resolver. Closes-Bug: #1906322 Change-Id: Ib9ba52147199a9d6d0293182d5db50c4a567d677
2021年07月28日 11:19:57 +10:00
fixup_ubuntu
fixup_fedora
}