-
Notifications
You must be signed in to change notification settings - Fork 41
Description
What happened:
I'm setting up a Wordpress site using the wordpress-operator. For media backing store, I was hoping to use S3.
I read through the CRD spec and found that it supports s3: media library as well as gcs: media library. So I created a definition block that should have made use of a bucket and stored media there. I tested it by visiting my Media library and upload/view some images. Instead of pushing/pulling the images from S3, it created a wp-content/uploads directory and stored the sample images in there.
spec:
media: # where to find the media files
# For S3, see: https://github.com/presslabs/wordpress-operator/blob/ce3af26178f206075ba7bde57985beb4181f59cb/config/crds/wordpress.presslabs.org_wordpresses.yaml#L1868
s3:
bucket: my-bucket
prefix: mysite
env:
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: wordpress-aws-secret
key: aws_access_key_id
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: wordpress-aws-secret
key: aws_secret_access_key
I also created the wordpress-aws-secret with proper credentials.
What you expected to happen:
I expected that after starting up mysite with the wordpress-operator, the Media library would either read/write images to S3 or at least start spewing errors due to misconfiguration. That is what happened when I put some dummy gcs: configuration settings in. (I don't actually have a GCS account.)
How to reproduce it (as minimally and precisely as possible):
- define a mysite wordpress CR spec
- use the spec configuration for the media setup above
- create a aws secret with two values to match the configuration above
Anything else?:
Is there anything else that needs to be done to configure Wordpress to use S3?