The service will soon emit messages when new images are uploaded. This
grants it access to publish under the fedora_image_uploader topic.
Specific topics under the org.fedoraproject.prod prefix look like:
fedora_image_uploader.azure.Fedora-Cloud-40.aarch64
fedora_image_uploader.container.fedora.f40
The Python package was renamed[0] upstream. Because the container
contains a default CMD that was updated to reference the new callback
path, the only thing that broke in production was the logging.
[0] https://pagure.io/cloud-image-uploader/pull-request/15
The cloud-image-uploader uses Pungi compose messages starting with
v0.3.0. This switches the routing keys and also adds a one-off task to
remove the queue before re-adding it to flush out any queued up messages
and remove the old topic bindings.
The latest import failed due to "ERROR: Unable to create local
directories(/.ansible/tmp): [Errno 13] Permission denied: b'/.ansible'".
Which implies the code is being executed from `/`, despite the WORKDIR
variable being set in the container image--I suspect this is a quirk of
kube/openshift that was not expected.
This change sets the workingDir to /srv/cloud-uploader, as specified in
the Containerfile, which should resolve the execution error.
Signed-off-by: Neil Hanlon <neil@shrug.pw>
env renders to "production" which is not what messages are published
under ("prod"). Match what other apps are doing and just use a wildcard
so it'll match anything. Since prod and stage are separate brokers this
is fine.
The image needs to be replicated to a region to be usable in that
region. It's likely we'll want to expand this list and potentially add
logic to the uploader to not replicate nightly images until they are
promoted to the latest image in the stream so I've templated it it
in the configuration.
Storage account names need to be globally unique. It seems fedoraimages
was already taken, so I've adjusted it to one that's not taken. It's
only used to import the images so the name doesn't really matter.
I assumed gallery names were unique per resource group, but this is not
the case. They're unique per subscription, oddly, so we need to use a
different name in staging.
The client certificate contains "cloud-image-uploader.stg" for the CN,
so our RabbitMQ name needs to match. Additionally, the queue name needs
to start with the username, so we need to adjust that as well.