# Fedora Data Centre Move - What it means for you?
to: devel-announce@lists.fedoraproject.org subject: Fedora Data Centre Move - What it means for you?
Good Morning,
As you may have heard in the past few months, most of the Fedora Infrastructure which is currently hosted in a data-center in Phoenix Arizona (USA) will be moving to a new datacenter in Virgina (USA) in just a few weeks now.
While we are doing our best to ensure a continuity of service to the project, there will be some consequences of this move.
The main issues will be that for several weeks: - *Fedora's build capacity will be significantly reduced*. - A few applications, not directly related to building Fedora, running in the Fedora Infrastructure will be offline (see link below)
Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though.
As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike).
In addition, during the move there will be no staging environment. This will directly impact very few people, but from an infrastructure point of view it also means that we try to avoid as much as possible updating applications (for example deploying a new account system or new releases) during that time.
To give you some insight on dates*: - The week of June 8th we will be moving services from one data-center to the other, so there will be ongoing outages as resources are moved from one data center to one with diminished capacity. - We are hoping to continue rebuilding the infrastructure in Virgnia the week of June 22nd as shipped hardware arrives at the new facility. - The target deadline to complete the entire move and return to normal capacity in Fedora Infrastructure is July 28th
A couple of final notes: - right after the end of the move, there is a mass-rebuild scheduled, so you could use this as an opportunity to let releng do the builds for you if you prepare everything in dist-git. - Please try to avoid pinging nirik or smooge in the coming weeks so they can focus on this delicate exercise, but if you run into them, I'm sure they will appreciate your support or/and some cookies on irc (nirik++ smooge++)! - Please bare with us while we're working on the move as responses to tickets/requests will likely be slower than usual.
A list of the applications that will be impacted by the colo move is available at: https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA
Thanks in advance for your understanding and help,
Aoife
* All the dates are subject to changes, going from networking issues, to servers dying because of the move, to a world-wide pandemic changing the working conditions in the data-center, but these are current estimates. _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org 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/devel-announce@lists.fedorapro...
On Wed, May 20, 2020 at 10:04 PM Aoife Moloney amoloney@redhat.com wrote:
Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though.
As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike).
Is it possible to see the current Koji build queue somewhere (as a graph/numbers), so that package maintainers can make an educated guess whether it's OK to submit their new not-so-important build, or whether they should rather wait and avoid increasing the load?
On Thu, May 21, 2020 at 03:25:08PM +0200, Kamil Paral wrote:
On Wed, May 20, 2020 at 10:04 PM Aoife Moloney amoloney@redhat.com wrote:
Practically, this means that your build will wait longer to find a builder available and as a result the whole build process will feel slower. The builds per say should not be impacted though.
As a result, if you know today that you have some important packaging work to do, we invite you to try to prioritize it now if possible. Otherwise, if you have the opportunity to plan this work for after the move is done, it would save some resources for builds that cannot/should not wait (CVEs and alike).
Is it possible to see the current Koji build queue somewhere (as a graph/numbers), so that package maintainers can make an educated guess whether it's OK to submit their new not-so-important build, or whether they should rather wait and avoid increasing the load?
Well, https://koji.fedoraproject.org/koji/tasks will list the current number of tasks ("Tasks 1 through 50 of 54" right now).
There are some reports under the reports tab, but I don't think any of them really apply here, except possibly 'cluster health' but it's a bit confusing to read.
Also, if you are doing some build(s) that you are not in a hurry for/are less important, you can launch the builds with: --background and they will run at a lower priority.
kevin
On Thu, May 21, 2020 at 10:43 AM Kevin Fenzi kevin@scrye.com wrote:
Also, if you are doing some build(s) that you are not in a hurry for/are less important, you can launch the builds with: --background and they will run at a lower priority.
That reminds me of a story I read, I think in one of Andy Tanenbaum's operating system books. As I recall, he labeled it as "probably apocryphal". It seems that, some decades ago, a mainframe at MIT was to be decommissioned. As the sysadmins were shutting things down, suddenly a student job popped up and started to run. It had been submitted years before, but at such a low priority that it had not been able to run until then.
As I said, of dubious veracity and even more dubious application to the current situation. :-)