Upstream puppet has a constraint on matching systemd that /run/systemd
has to be around; this fails when building with dib in a chroot where
we're not actually running.
A full solution has to take into account Debian and multiple init
systems (see linked issues). For the moment, just comment it out.
Change-Id: I6e4832caf6162a67408c34151b6e1d641a75fb8b
This removes centos6 support from install_puppet.sh because centos6 is
no longer supported so this code is dead.
Change-Id: If59f10a6a9c576b1299b0e49a2e82d2a1a1d7ecf
As described in the comments, there is a depdency bug which means some
python module builds fail without the config provided by this package.
Pre-install it before we start installing things.
Change-Id: I3c8615f17e47956f258fee10caa9a57c99c719b8
See Ibcb27199f0ecf3b1e3d927be42112e2ebcb5cd79 for part 1
So it turns out that installing the latest systemd and restarting
isn't enough to get this working. It seems that a "systemctl
daemon-reload" is required between installing iptables-services and
enabling iptables (note, this should *not* be required; the
iptables-services .spec file does a "systemctl preset
iptables.service" which is documented as being equivalent to a
daemon-reload. You can see this failing in the selinux denials in the
referenced bug).
What does seem to work is upgrading to the latest selinux-policy
before installing iptables, so add this in.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1261747
Change-Id: I4c1983019834d676f99becfde4ffd3f8de19c3a6
As described in the comments, there is potential for systemd to not be
able to enable services after it is upgraded until it is restarted.
I do not think we see this during puppet runs in the gate because we
disable selinux, but it can be triggered (see
I0750de9e75b63190531a3d39a5fcbb19f8e8c49e)
This is a small work-around to pre-install systemd and restart it
before doing the rest of the system upgrades
Change-Id: Ibcb27199f0ecf3b1e3d927be42112e2ebcb5cd79
CloudLinux is a commercial RHEL-based distribution
aimed specifically at web-hosting usage.
You may read about more: https://www.cloudlinux.com/about/compatibility.php
We need to test CloudLinux in VMs in our third-party CI,
and hence to customize VM images with diskimage-builder,
We use Openstack Infrastructure elements from openstack-infra/project-config.
Element for installing puppet (puppet/install.d/05-puppet) references
this script.
It is cumbersome to maintain a copy of this file locally, so
we propose this trivial change which will make
install_puppet.sh work for CloudLinux.
In case someone doesn't have CloudLinux at hand,
it has a version file like:
> cat /etc/redhat-release
CloudLinux release 7.1 (Vladimir Komarov)
> ls -la /etc/redhat-release
lrwxrwxrwx 1 root root 18 Jul 17 14:03 /etc/redhat-release -> cloudlinux-release
Change-Id: I01285d92d823b5e4fb4943bc31ff3ec6361eb5a2
This COPR repo has an updated git package that includes the single
patch discussed in [1] to aleviate slowness in https cloning. This
has been tested with [2] where the gate-infra-puppet-apply-centos6 job
has been stable.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1237395
[2] https://review.openstack.org/198177
Change-Id: I29153ca05c537e6cd61365b3a24cc6854f6d7100
After the dependent changes merge, no jobs are using devstack-f20
nodes so we can remove them.
The one specific work-around in the puppet-scripts is removed. The
logging configuration for nodepool is also regenerated.
Change-Id: I435f0d95dbe7f5d8e90c1fe8368dd42ebb241c88
Depends-On: Ifa742ba5bdae0b796b8b92336e41234fd8b7939e
Depends-On: I4773d3ba1ee29880e928e25257ce188e7bd7dc90
We haven't been running an update on the centos7 hosts since the
beginning (e.g. I80024d1afdb4e40d5fe9793ab2ec443b887c5fa8); it looks
like this was just forgotten.
Change-Id: I0eb7119b03dbbfe6697a656dfe57186f9a1ef791
The issue with F20 grubby killing the extlinux.conf file is specific
to RAX, because they ship a different file. So apply this only when
on RAX because it is causing issues elsewhere.
This is not needed long-term. We are close to removing f20 nodes
anyway with just a few jobs, all of which can be converted to centos.
All changes to do this are in-flight, see the dependency chain from
[1]. At that point all this goes away anyway.
[1] https://review.openstack.org/167443
Change-Id: Ibb5a455d690aa1298c2f625da20e606914bf632a
Before this the file would be hanging around in the git repository untracked.
I would also be happy with hiding the script from git using .gitignore
Change-Id: I718c63b7492329cbee5f457362d849628353d7c4
Something about Fedora 20 and the rax layout of /boot/extlinux.conf
makes grubby fail to correctly set the correct default when the kernel
package is updated. I found what appears to be the bug (referenced
inline) but there is no clear solution. However, testing shows the
rawhide version works OK, so we can just install that.
Change-Id: I0880c850dedada893d6e3e7e922c2994ece74930
Use a little trick we deployed in devstack to install the latest
epel-release rpm; first setup a disabled "bootstrap" repo to epel and
then yum install the latest package.
This should avoid us having to touch anything when EPEL decides to
create a new release.
Change-Id: I9e43de3770b6dff03fd87edbf5decbae9780d8db
This reverts commit d935a862895c8d7095774b4093879acd6e5ab09d.
The blockers for setuptools 8 compatibility should all be resolved
now.
Change-Id: I39b0103a999690ec63ab6963af4962c070ee8768
Latest release of setuptool 8.0 made several versions used in
requirements.txt of OpenStack projects invalid. Instances:
* SQLAlchemy>=0.8.4,<=0.8.99,>=0.9.7,<=0.9.99 in oslo.db 1.2.0
* python-neutronclient 2.3.9.40.g9ed73c0 in openstackclient
Cap '<8.0' is set as a temporary fix until a better solution
comes up.
Change-Id: I74530bd52cf21951d9b7c26133ed21f46c89c7d1
The 00-puppet.pref file is now a template that's generated based on
$pin_puppet set in your manifest.
Change-Id: I7548f3ddf02b8d0b5c0233f74407cf22038679e4
puppet looks for pip-python (rather than pip) when osfamily is
redhat. Somehow this wasn't causing a problem before (presumably
pip-python package was left behind but something has changed
upstream) and now we need to create a symlink for rhel6 as well.
Change-Id: I1f11aa7f6b33aa846e10715dd1653bb43e1c9d7e
As we discovered in the course of upgrading puppetboard the puppetdb
package is upgraded independently of the puppetdb-terminus package,
but in fact it will break if they don't match. We now pin them to
the same values for safety.
Change-Id: I628129997e084ec5e4cb18947fa7e2362c9b4ba5
This reverts commit 5be2e2f18ac1f4489be760717519252ba20d4fba.
Yay! We've sucessfully upgraded to puppet3 and the sun is shining!
Start managing apt pins for puppet again, and also, set the default
to be 3.x everywhere.
Change-Id: I80db5b5e154a3849914aa348e1eabadd0a2ad936
* check to see if lsb_release exist or not, if not
install it. Updating logic to match other platforms.
Change-Id: Ic6e8625d90db9076a9ca08669fe11ca3cfe28b7b
This enables install_puppet.sh to run successfully on
trusty with PUPPET_VERSION=3 set.
Add a util directory and a puppetmaster bootstrap
shell script.
Puppetdb-terminus versions are the same in trusty and
precise but are different than the puppet version number.
Also puppetdb-terminus isn't present in the puppetlabs
repositories.
Along with this I have done sufficient testing to use
puppet version 3.6 with confidence.
Work has been done to enable directory environments as well.
Change-Id: I925fa6ac1ed9fc9c0b5e9e616fb071bf7a815436
The pip-python symbolic link creation is the last
step in the install_puppet.sh on Fedora.
If the symbolic link already exists,
the exit status of the script will be failed.
After this change the pip-python link will be created by force,
so it will not fail on second run, and it may correct an old incorrect
link.
Change-Id: I0b25b1d69ee5e851f15e44fd16f62c29676d2075
Install the right EPEL and puppet rpm's for RHEL7/Centos7.
I have tested this on one of the CentOS nightly builds and
run_puppet.sh, install_modules.sh and a puppet apply of
openstack_project::single_use_slave works as expected
Change-Id: I80024d1afdb4e40d5fe9793ab2ec443b887c5fa8
Installing setuptools with pip overtop of system setuptools
has evil and destructive results. Kill it with a hammer
before re-installing.
Change-Id: I556b2cec249ef46e09ffca3cd75521e0beeb7779
Add upgrading of setuptools to prepare-node.sh. We want this
to happen everywhere, and quite honestly I'm not sure I
fully trust trying to get puppet to do it.
This reverts commit 3bc3a11244f4a4e28a4c97feec4987940d0f34cc.
Change-Id: Idf09be0e1e086e20f9e71ceb26602fea1fc62173
Instead of looking for an argument, change the install_puppet.sh script
to look for an environment variable to switch to installing puppet3.
Also export this environment variable in prepare_node.sh (albeit with a
default value that does not install puppet3).
Change-Id: I04bee2fa5bb70a4d763edb2f3d30f117cad5d65b
As part of move to add a puppet3 master the facter-2* exclusion on
centos6 was removed. We need this exclusion so add it back.
Change-Id: I085b242739a572cf2daeb514a46e93b36104d3ee
This change modifies install_puppet.sh to accept a --three option
setting it to install the latest puppet available. It also creates
a node definition for the puppetmaster.o.o node, the new 3 master,
and the master of the future. Changes were made to various classes
to allow the pinning to version 2.x to be turned off.
Change-Id: I805d6dc50b9de0d8a99cf818d22d06c2dea6090a
A small clean-up of the install_puppet.sh script to enhance
readability and to simplify adding support for extra distributions
- add distribution check functions
- move puppet installation for each distribution into its own
separate function
- move pip installation into a function
- add/expand several comments
Change-Id: I5d5f71fde607ace528b7372e2deadccbea58bd2f
I hit an issue with a system with curl *and* wget installed. The curl
download failed, leaving a corrupt get-pip.py and thus the wget
download started (which then saved to get-pip.py.1). The script then
tried to run the corrupt version. Although re-running is uncommon
unless you're manually deploying the scripts, best to also check for
the file first or these commands both re-download to get-pip.py.X
Change-Id: I6b70b4b7bb3d963ba70d71388c701951932e9adb
The pypa team has made a new static location for get-pip.py. Instead
of downloading from github, we should use this.
Change-Id: Ifb7f00447d4a19f20f6413fa7fece5913de092f8
There are few things that are different for our slaves on trusty. Of
note, we don't want to pin puppet, and we need to provide a version
for postgres.
Change-Id: Ibee78cd4fbeef2e6af43379d2bc3a0f0e9767a06
We nolonger need or want setuptools_git installed anywhere.
get-pip no longer needs ez_setup.py first. Also, github broke
redirection on Fedora, so change the URL.
Change-Id: I16d64695bf05e672fdc12236424b62e5cd5e5dc7
raw.github.com now redirects to raw.githubusercontent.com and various
curl commands are failing unless they include "-L".
Change-Id: I07d9c2f9caa2abc82ffd57435335875df5fbc96f