In our wheel build jobs, we try to install puppet with this script on
bionic nodes. However, there is no <5 puppet distributions for
bionic.
This detects bionic and installs from puppetlabs (note the name seems
different as it's not pc1 any more)
Change-Id: Ica34b7525bab53f8a6d161401f7fb9a2dbe37bc3
There is no need to configure epel, if already installed when
installing puppet.
Change-Id: Ideba593a78a8017c3855548377193887183818b0
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
There are some assumptions made about the puppet config paths that
aren't applicable for puppet 4. Configuration, including modules,
belongs under /etc/puppetlabs. It's also no longer necessary to fix up
the templatedir or server configs in puppet.conf.
Change-Id: I3b544b6ce4a96a7a2478522a78402f77ff86a5a5
This reverts commit 37c26280bf.
This was originally removed so that EPEL would not be installed in
our nodepool images. We no longer run this script when creating
those images, so it can be safely restored. It should be restored
because without this, we are unable to spin up a cgit server
(which requires epel).
Change-Id: I93e6487ab9a2eae5f927abf43aea7e3e19c5ac9e
Because we no longer use puppet to manage our DIB images in nodepool,
we can not remove this. We would only add it to install openvswitch
and other binaries for devstack.
And since our only centos servers are git, we can also remove this.
Change-Id: I39c5aee70cffe0e270a605cbe669cb09a8f71b09
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We no longer have a puppetmaster, remove it do avoid trying to lookup
one when we first start puppet.
Change-Id: I38267eeb909aad8cafd1e2bf3e11ee52924d10c7
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Currently puppetdb and puppetboard have been broken for some time (+1
year) and with ubuntu precise becoming EOL it is prime for deleting.
This leaves openstack-infra with a gap in reporting for non-root
users. As such, as proposal is in the works to maybe use ARA.
Change-Id: Ifc73a2dba3b37ebe790a29c0daa948d6bad0aa33
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We get a lot of
puppet-agent[9836]: Could not request certificate: Failed to open TCP connection to puppet:8140
when launching Xenial nodes. It seems to be because puppet is started
by the package install now. Ensure it is stopped before we disable
it.
Change-Id: I4a3d0f4516941494e7c37e8e6859f28ef5b54c10
Newer Ubuntus like Xenial don't necessary have python2 preinstalled. If
on Ubuntu and `python` is not present we install the python package so
that pip and ansible are happy later on.
Change-Id: Ia81c33b845664f35fba6fa8259bc83f8bcfec0e0
This patch adds a global PUPPET_VERSION variable to allow changing the
installed puppet version. The default version remains 3. CentOS and
Ubuntu support setting it to 4. Fedora already installs 4 by default
from the fedora repositories, and we defer worrying about opensuse and
gentoo for now since we do not use those operating systems in the
control plane and we no longer use puppet to build CI images.
The script adds the new "Puppet Collections" repository and changes the
name of the package to 'puppet-agent' when installing version 4. See the
install guide[1] for more details.
[1] https://docs.puppet.com/puppet/4.0/install_linux.html
Co-authored-by: Caleb Boylan <calebboylan@gmail.com>
Change-Id: Id829922875d495bca9ba11a3fe3428a7ebb2cd58
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 fce3e9d93b.
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
Tony Breeds