I like C too.
Currently, when something breaks on the websites (the most common issue
is outdated content), the websites team needs to reach out to infra to
understand what's happening and ask them to check the build logs.
Using Openshift is not a widespread skill, and it can be a bit difficult
to debug anything when you don't know where to look, how to trigger a
new build, or just don't have any access.
With C, we are offloading that task to the website team, who are then
able to use the tools they know to deploy and solve any issues related
to the build process that may arise.
Now, the real question is, are we going to allow that?
Giving access to such s3 storage to a third party (I'm talking about
GitLab here since the s3 access key will be stored on their platform)
can be a potential security concern.
If this key gets stolen, it basically gives direct access to our
proxies.
I feel like I've somewhat answered my own question, but I would love
your opinion on this :)
-darknao
On 2022-11-24 18:59, Ahmed Almeleh wrote:
My vote is for C. If we can reduce the amount of steps required to
implement service redundancy. Deployment to S3 provides out of the
box access to the public domain and is straightforward.
Regards,
Ahmed Al-meleh
Fedora QA Contributor
On Thu, 24 Nov 2022, 17:28 Francois Andrieu,
<darknao@xxxxxxxxxxxxxxxxx> wrote:
B) Same as before, with a twist
We build on Openshift, but instead of going through NFS and
sundries with rsync, we store the websites on S3 storage provided by
Openshift, then we sync the proxies using `s3cmd sync`.
C) Same as B, but with an external builder
We already build the new websites on Gitlab CI, and since the S3
gateway is accessible from the outside, we could just push the build
artifacts to s3 directly from GitLab CI. Then sync the proxies from
it.
-darknao
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
