
These two roles no longer need the delegation variable used in testing, so it is removed. Role execution now happens on the executor. Since the remote servers are still on the worker node, we open the firewall on the remote node in both cases. In the artifactory role, the ensure-docker role is moved to a "roles" section for simplicity. Additionally, one of the artifactory API calls is wrapped in retries as a precaution since I saw that fail in local testing. Change-Id: Ia4409edc217e1935775a5aece2e7d9bcfd935762
Upload logs to S3
Before using this role, create at least one bucket and set up appropriate access controls or lifecycle events. This role will not automatically create buckets.
This role requires the boto3
Python package to be
installed in the Ansible environment on the Zuul executor.
Role Variables
This role will not create buckets which do not already exist. If partitioning is not enabled, this is the name of the bucket which will be used. If partitioning is enabled, then this will be used as the prefix for the bucket name which will be separated from the partition name by an underscore. For example, "logs_42" would be the bucket name for partition 42.
Note that you will want to set this to a value that uniquely identifies your Zuul installation.
The endpoint to use when uploading logs to an s3 compatible service. By default this will be automatically constructed by boto but should be set when working with non-aws hosted s3 service.
Conventional authentication
To authenticate with a conventional AWS access key and secret, supply the following two variables:
AWS access key to use.
AWS secret key for the AWS access key.
OIDC federated authentication
It is also possible to authenticate usinc OIDC, including using Zuul as an ID provider with Zuul's OIDC token secrets feature. Use the following variables to do so:
The ARN of the AWS role to assume when authenticating.
The token issued by the federated IDP. If the IDP is Zuul, this should be the token secret.