We want to stop puppet service from being enabled on boot, so use the
update-rc.d command. Otherwise we get the following errors:
`service puppet disable` runs failed.
Usage: /etc/init.d/puppet {start|stop|status|restart|force-reload|reload}
Change-Id: Ie0c6366284de156151e6831de16579321e5d7bef
Signed-off-by: dongwenjuan <dong.wenjuan@zte.com.cn>
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We don't need to stop the puppet service in single_use_slave, so as part
of emptying out openstack_project::template, move that resource
to openstack_project::server.
We still need to disable the service during the image build so add that
to the install_puppet.sh script.
Change-Id: I11db1b49f083c7a30e7908ba5a4a7df9d4033c9f
In our effort to deprecate puppet for our zuul workers, start to break
our dependency on install_puppet.sh. We now configure pip and
virtualenv using DIB.
Change-Id: Ie110fd50750ffc48c1ed939b18b68e40af6331ee
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
EPEL is not really helping us test, because upstream RDO (and hence
centos openstack) are designed to run without it. In fact it seems to
actively get in the way.
Installing EPEL here is really a hang-over from the snapshot days when
we'd boot provider images without it. We do need EPEL for bringup but
should have it default disabled so we whitelist use; see depends-on
which moves it into dib.
Depends-On: I2d060e048f9106292f9024efe0fd1d529d801a30
Change-Id: If6cf1bc300c6b59a8defb09fb3a3a1254e392a43
Xenial images by default don't come with python2 installed.
Unfortunately ansible requires python2 on the host to run (for now,
though [1] is in preview). In the mean time, ensure we have
python-minimal.
I think that under standard conditions, this is being dragged in by
other dependencies anyway. The place I noticed was launching a
vexxhost control-plane node, using their Xenial base images.
[1] https://docs.ansible.com/ansible/python_3_support.html
Change-Id: I0e4020e9b8407271c88c3c5ac332393f6dd28418
With the current code, I get puppet version 3.6.2 installed.
puppet noarch 3.6.2-3.el7 epel 1.2 M
With this change I get new puppet 3.8.7 installed.
puppet noarch 3.8.7-1.el7 puppetlabs-products 1.5 M
Change-Id: I680a7630986cf7a2b4989a3e853ddb409b228cea
The python-requests package has been split into a python2-requests
package on Fedora (that provides python-requests). Install this so we
don't end up with the same problem of python2-requests overriding the
pip version later.
Change-Id: I79b52c40c2521bcc36b690112639584b6076f0d1
Emaint sync needs to be called with an argument, in our case '-a' is
sufficient. It also can request user input, so we allow it to sync
automatically as well.
Change-Id: Ida47e14f883fdd29ad375fd47992b4662911d1d1
This adds support for installing puppet on Gentoo. I've packaged
puppet-agent, which is upstream's package for general use (deb based).
It is based on Puppet 4.
Change-Id: If0c4bd83af822b0d0208a97561fffecbe495c5a9
As a host may not have wget add logic to try curl too.
Change-Id: I9a2ffeff08926eec5f4fee04fde0ddcc19004493
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We had it pinned to an specific version, which can cause problems
when new packages are released, forcing to bump periodically.
Instead of that, consume the latest rpm that will give us the
latest published version.
Change-Id: Idc9f40cdc8a9e47bdf9baa141c09e97f7884d3cf
This is our first attempt to add support for ubuntu xenial.
Change-Id: I857a85177e9281b23f130453180764839e19a551
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Clear out the meta-data provided by the rpm package, so pip does a
reinstall. Fix for If3f244ed4f62da25dc42813b4bda2f374f002517
Change-Id: Ic3bd801c0f57a2453d3563aaa4cf778aa0a9f9bf
The fedora-minimal builds do not include the package python-requests,
but some of the later puppet (via zuul) will end up pip-installing it.
This leaves the system in a very precarious state -- if the
python-requests package ever gets installed over the pip-installed
package everything is broken because of the vendoring/symlinking
issues mentioned in the comment.
This is the most logical place to fix this up so we're in a consistent
state with a pip-managed requests package. Devstack can clean this up
(I6b06dcd897999e0642b387e8d13a473934ed0956) but better to have the
base system in a consistent state.
Change-Id: If3f244ed4f62da25dc42813b4bda2f374f002517
The centos-minimal dib build is failing as it tries to cache some
packages that have dependencies on python-setuptools.
Since I556b2cec249ef46e09ffca3cd75521e0beeb7779 we have been
installing a yum.conf that has an "excludes" for this package.
We have not noticed this on the existing dib builds because they have
python-setuptools already installed in the base-image as part of the
cloud-init install. So this satisfies the dependency; however on the
minimal builds the package is not there, and the exclude means the
packages dependencies that can not be satisfied and the build stops.
The original code has since been removed. I think the problem of some
parts of the packaged setuptools conflicting was probably due to the
large version delta between whatever was in CentOS6 to a current pip
install. Clearly the issue doesn't exist with pip installing over the
Centos7 version (because it's working now), but for an abundance of
caution let's pre-install the packaged version, clear it out, then
install from pip.
Change-Id: I35408717dc340271dea3d857bc19ea1590e84361
This reverts commit fce3e9d93b55dfc59059fa46f038473bcf0a46fa.
pip 8.0.1 rolled back the breaking change.
From the release notes at: https://pip.pypa.io/en/stable/news/
8.0.1 (2016-01-21)
Rollback the removal of the ability to uninstall distutils installed
items until a future date.
Change-Id: I3c9f2ed491689cbdafe10f6115ba3f61a0f03215
When we create a new server and install puppet, we also install pip.
That's awesome, except when pip >=8 breaks us. For now, pin it.
Change-Id: Id12f866f577c3ca2405a6049084c3cb0af82fde5
dnf is a drop-in replacement for yum on Fedora>=22; add $YUM so we use
dnf there and avoid the deprecation warnings.
Change-Id: I3d62d8f6d8705b2cf840b63ffd82927a408d75aa
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
