We currently only have letsencrypt_test_only as a single flag that
sets tests to use the letsencrypt staging environment and also
generates a self-signed certificate.
However, for initial testing we actually want to fully generate
certificates on hosts, but using the staging environment (i.e. *not*
generate self-signed certs). Thus we need to split this option into
two, so the gate tests still use staging+self-signed, but in-progress
production hosts can just using the staging flag.
These variables are split, and graphite01.opendev.org is made to
create staging certificates.
Also remove some debugging that is no longer necessary.
Change-Id: I08959ba904f821c9408d8f363542502cd76a30a4
The Ariship, StarlingX and Zuul git sites "hide" the namespaces of
their repositories, so need additional rewriting to readd them when
redirecting to the OpenDev Gitea service. In an effort to avoid
rewrite loops, pattern match them on specific repository name
prefixes so they won't match the namespaces being inserted.
Change-Id: I0a19393147eca5d75b286dfb8bda5665f31a2a2b
Task: #29705
Currently ansible fails on most puppet4 hosts with
TASK [puppet-install : Install puppetlabs repo] ********************************
fatal: [...]: FAILED! => {"changed": false, "msg": "A later version is already installed"}
As described inline, the version at the "top level" we are installing
via ansible here is actualy lower than the version in the repo this
package installs (inception). Thus once an upgrade has been run on
the host, we are now trying to *downgrade* the puppetlabs-release
package. This stops the ansible run and makes everything unhappy.
If we have the puppet repo, just skip trying to install it again.
We do this for just trusty and xenial; at this point we don't have any
puppet5 hosts (and none are planned) and I haven't checked if it has
the same issues.
Change-Id: I55ea8bfbfc40befb1d138e9bc0f95b120f8f5dbd
This file was accidentally dropped from
I3e762d071cc609856950898b36f1903fe52840a6 during a rebase.
Change-Id: Iabc1db2aa029d7ff73b742ed63d367d8daa39187
The ansible-role-puppet role manages puppet.conf for us. These two roles
are currently fighting each other over the presence of the server line
in puppet.conf. Avoid this by removing the removal of this line and the
templatedir line from the new puppet-install role since
ansible-role-puppet was there first. Basically just trust
ansible-role-puppet to write a working puppet.conf for us.
Change-Id: Ifb1dff31a61071bd867d3a7cc3cbcc496177e3ce
This created confusion when updating configs to handle journald. Remove
the unused files and update docs to point at the proper config location.
Change-Id: Ifd8d8868b124b72a86cf7b5acb30480e72b903ed
This is an initial change for deploying letsencrypt certificates on
graphite01.opendev.org. As we are still in a testing phase, use test
mode.
Change-Id: I3e762d071cc609856950898b36f1903fe52840a6
This enables automatic reload of the replication configuration for
review.
Depends-On: https://review.openstack.org/650049
Change-Id: I6f43e2e234a452a860fb669124589120476acb18
This enables automatic reload of the replication configuration for
review-dev.
Depends-On: https://review.openstack.org/650049
Change-Id: I3be630339870d527bedcfbd84b8dc8084dc10f4b
We don't have python2 on bridge.o.o, force python3.
Change-Id: Ie8eb68007c0854329cf3757e577ebcbfd40ed8aa
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This change contains the roles and testing for deploying certificates
on hosts using letsencrypt with domain authentication.
From a top level, the process is implemented in the roles as follows:
1) letsencrypt-acme-sh-install
This role installs the acme.sh tool on hosts in the letsencrypt
group, along with a small custom driver script to help parse output
that is used by later roles.
2) letsencrypt-request-certs
This role runs on each host, and reads a host variable describing
the certificates required. It uses the acme.sh tool (via the
driver) to request the certificates from letsencrypt. It populates
a global Ansible variable with the authentication TXT records
required.
If the certificate exists on the host and is not within the renewal
period, it should do nothing.
3) letsencrypt-install-txt-record
This role runs on the adns server. It installs the TXT records
generated in step 2 to the acme.opendev.org domain and then
refreshes the server. Hosts wanting certificates will have
pre-provisioned CNAME records for _acme-challenge.host.opendev.org
pointing to acme.opendev.org.
4) letsencrypt-create-certs
This role runs on each host, reading the same variable as in step
2. However this time the acme.sh tool is run to authenticate and
create the certificates, which should now work correctly via the
TXT records from step 3. After this, the host will have the
full certificate material.
Testing is added via testinfra. For testing purposes requests are
made to the staging letsencrypt servers and a self-signed certificate
is provisioned in step 4 (as the authentication is not available
during CI). We test that the DNS TXT records are created locally on
the CI adns server, however.
Related-Spec: https://review.openstack.org/587283
Change-Id: I1f66da614751a29cc565b37cdc9ff34d70fdfd3f
The zonefile isn't required in the config file as we are just
transfering from adns1. Since we don't create the directory for the
files, it results in warnings in the nsd logs -- this can be a
confusing red-herring in a debugging situation.
Change-Id: I3e16a359549707a4a3967f580161dec9e71ab689
Related-Bug: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4244
Change I754637115f8c7469efbc1856e88bbcb6fb83b4ce moved a bunch of log
collection to use "stage-output". This uses "fetch-output" which
automatically puts these logs in hostname subdirectories; but it does
not have an option to put it in hosts/hostname as we were doing with
the other logs.
Although we could add such support, it probably doesn't make sense as
most other multinode jobs will have the same layout with the host logs
at the top level. Remove the intermediate "/hosts/" directory on
system-config jobs so all logs remain at the top level, and we don't
have this confusing split as to where logs are for each host.
Change-Id: I56bd67c659ffb26a460d9406f6f090d431c8aa79
The only thing used in the CI is the actual repomd
repositories located under repo/{non-,}oss.
In Leap 15.0 over the last few months various images
were added, but we don't need them. Remove them
from the mirroring. The structure looks like this:
distribution/leap/15.0/:
- jeos
- live
- repo
Change-Id: I00b888b4b11313d83c0025c388937c13a69b1da5
