letsencrypt: split staging and self-signed generation

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
This commit is contained in:
Ian Wienand 2019-04-10 07:31:26 +10:00
parent 00efd089a2
commit 86c5bc2b45
8 changed files with 24 additions and 18 deletions

View File

@ -1,5 +1,5 @@
# NOTE(ianw): 2019-03 initial bringup in testing only mode
letsencrypt_test_only: True
letsencrypt_use_staging: True
letsencrypt_certs:
main:
- graphite01.opendev.org

View File

@ -7,13 +7,19 @@ on the host.
**Role Variables**
.. zuul:rolevar:: letsencrypt_test_only
.. zuul:rolevar:: letsencrypt_self_sign_only
If set to True, will locally generate self-signed certificates in
the same locations the real script would, instead of contacting
letsencrypt. This is set during gate testing as the
authentication tokens are not available.
.. zuul:rolevar:: letsencrypt_use_staging
If set to True will use the letsencrypt staging environment, rather
than make production requests. Useful during initial provisioning
of hosts to avoid affecting production quotas.
.. zuul:rolevar:: letsencrypt_certs
The same variable as described in ``letsencrypt-request-certs``.

View File

@ -1 +1,2 @@
letsencrypt_test_only: False
letsencrypt_use_staging: False
letsencrypt_self_sign_only: False

View File

@ -5,12 +5,10 @@
- name: 'Run acme.sh driver for {{ item.key }} certificate issue'
shell:
cmd: |
/opt/acme.sh/driver.sh {{ 'selfsign' if letsencrypt_test_only else 'renew' }} {{ acme_args }}
/opt/acme.sh/driver.sh {{ 'selfsign' if letsencrypt_self_sign_only else 'renew' }} {{ acme_args }}
args:
chdir: /opt/acme.sh/
register: acme_output
- debug:
var: acme_output.stdout_lines
environment:
LETSENCRYPT_STAGING: '{{ "1" if letsencrypt_use_staging else "0" }}'
# Keys generated!

View File

@ -15,9 +15,11 @@ provision process.
**Role Variables**
.. zuul:rolevar:: letsencrypt_test_only
.. zuul:rolevar:: letsencrypt_use_staging
Uses staging, rather than prodcution requests to letsencrypt
If set to True will use the letsencrypt staging environment, rather
than make production requests. Useful during initial provisioning
of hosts to avoid affecting production quotas.
.. zuul:rolevar:: letsencrypt_certs

View File

@ -1 +1 @@
letsencrypt_test_only: False
letsencrypt_use_staging: False

View File

@ -10,12 +10,9 @@
/opt/acme.sh/driver.sh issue {{ acme_args }}
args:
chdir: /opt/acme.sh/
environment:
LETSENCRYPT_STAGING: '{{ "1" if letsencrypt_test_only else "0" }}'
register: acme_output
- debug:
var: acme_output.stdout_lines
environment:
LETSENCRYPT_STAGING: '{{ "1" if letsencrypt_use_staging else "0" }}'
# NOTE(ianw): The output is challenge-domain:txt-key which we split
# into a tuple here. acme.sh by default puts the hostname into the

View File

@ -1,4 +1,6 @@
# We don't want CI tests trying to really authenticate against
# letsencrypt; apart from just being unfriendly it might cause quota
# issues.
letsencrypt_test_only: True
# issues. As we don't have the authentication keys exposed in the
# gate, only generate a place-holder self-signed cert for testing.
letsencrypt_use_staging: True
letsencrypt_self_sign_only: True