Re: Rethinking fedora websites deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



What is likelyhood of Openshift going down?   A would be best solution if stable enough.

copperi

From: Francois Andrieu <darknao@xxxxxxxxxxxxxxxxx>
Sent: Thursday, November 24, 2022 7:28 PM
To: infrastructure@xxxxxxxxxxxxxxxxxxxxxxx <infrastructure@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Rethinking fedora websites deployment
 
Hi everyone!

The Websites & Apps team is currently working on rewriting all major Fedora websites (such as getfedora, spins & alt) and I believe this is a good opportunity to revisit the current deployment workflow and try to make it simpler.

Currently, websites are being built in Openshift, with a cronjob running every hour that fetches code from git, builds it, then saves it to an NFS share.
That same NFS share is also mounted on sundries01, which exposes it through rsync for proxies to sync it, then serve it to the world.

I have a few solutions in mind to replace that, and I would like your input on them.

A) Full Openshift
    We can build, and deploy the websites directly in Openshift, and serve it from here. Just like silverblue.fp-o.
    While this is probably the most straightforward solution, it has one major downside: if Openshift is unavailable for any reason, our major websites become also unavailable.
    I believe this is why we are still using our proxies to host them, as such a scenario is unlikely to happen on every single one of them at the same time.

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.

D) Keep using the Openshift->Sundries->proxies workflow

E) Your solution here.

We could also improve B and C by adding fedora-messaging to the mix to trigger a proxy resync as soon as a new build is available instead of doing so every hour.

What do you all think?

-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
_______________________________________________
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

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux