Apache Infrastructure Team

Sunday January 27, 2019

Rate-limiting on Apache services

Over the past few days we have implemented rate limiting on selected services across the ASF.

As our foundation grows, so do the number of users and robots utilizing our services. In order to accommodate as many as possible with what resources we have, we have opted to implement rate-limiting to ensure that everyone can get their fair share of use of our services across the globe. The first services to have rate-limiting implemented are:

  • JIRA (issues.apache.org)
  • MoinMoin Wiki (wiki.apache.org)
  • BugZilla (bz.apache.org)

If you are a normal user of our services:

This very likely will never affect you, and you can go about your business just like normal :) If you DO experience errors or 429 (rate limited) response codes, please do let us know.

If you are a robot or otherwise automated tool:

There are now limits in place for how much CPU time you can use, varying from service to service. If you get limited, you will receive a HTTP 429 response instead of the normal 200, and a short text blob will explain that you have crossed our resource limits and have been rate-limited. It will also explain why, and when you can expect to be unblocked again (generally within two minutes time). Scrapers, bots etc using our services should check for a 429 response code and act accordingly (or just slow down the discovery pace in general, as that benefits all of us).

A general note about the rate limiting system, now and in the future:

Rate limits are applied across IP blocks to discourage distributed abuse, thus if you have abusing a service, would potentially also be affected by the rate limits till they expire.

Later this year, we will be rolling out rate limits on more services, and we encourage people automating tasks to honor the 429 responses across all ASF services.

We would also like to point out that there are, as before, additional global limits in place regarding the use of our services, which can be found at: https://www.apache.org/dev/infra-ban.html

Thursday January 10, 2019

Roller updated to 5.2.2

We've updated blogs.a.o to the latest version of Roller, 5.2.2!!

Friday December 07, 2018

Relocation of Apache git repositories on git-wip-us.apache.org to gitbox.apache.org


Hello Apache projects,

I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming months. All repositories will be moved to the new gitbox service which includes direct write access on github as well as the standard ASF commit access via gitbox.apache.org.

Why this move?
The move comes as a result of retiring the git-wip service, as the hardware it runs on is longing for retirement. In lieu of this, we have decided to consolidate the two services (git-wip and gitbox), to ease the management of our repository systems and future-proof the underlying hardware. The move is fully automated, and ideally, nothing will change in your workflow other than added features and access to GitHub.

Timeframe for relocation
Initially, we are asking that projects voluntarily request to move their repositories to gitbox. The voluntary time frame is between now and January 9th 2019, during which projects are free to either move over to gitbox or stay put on git-wip. After this phase, we will be requiring the remaining projects to move within one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

  • Consensus in the project (documented via the mailing list)
  • File a JIRA ticket with INFRA to voluntarily move your project repos over to gitbox (as stated, this is highly automated and will take between a minute and an hour, depending on the size and number of your repositories)

To sum up the preliminary timeline;

  • December 9th 2018 -> January 9th 2019: Voluntary (coordinated) relocation
  • January 9th -> February 6th: Mandated (coordinated) relocation
  • February 7th: All remaining repositories are mass migrated

This timeline may change to accommodate various scenarios.

Using GitHub with ASF repositories
When your project has moved, you are free to use either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes. To be able to use GitHub, please follow the primer at: https://reference.apache.org/committer/github We appreciate your understanding of this issue, and hope that your project can coordinate voluntarily moving your repositories in a timely manner.

All settings, such as commit mail targets, issue linking, PR notification schemes etc will automatically be migrated to gitbox as well.

Wednesday August 19, 2015

Planned downtime for ReviewBoard

The ReviewBoard vm ran out of space and despite our best efforts to fix the space issue without restarting the service, that is the only option left.

The plan is to restart the vm on Thursday August 20th at 21:00 UTC (14:00 PDT), but if it fills up again before then, the resize will take place earlier.

A tweet via @infrabot will be tweeted 1 hour before the scheduled downtime and a planned maintenance notice will be posted to status.apache.org.

The actual downtime should take no more than 30 minutes.

The next email about this will be after the service has resumed from the planned downtime.


Geoff Corey

Wednesday June 10, 2015

Confluence Wiki service to be restarted

Hi All,

There will be a planned reboot of Confluence on Friday 12th June at 18:00 UTC+1

This is a blog post notice as recommended in our Core Services planned downtime SLA.

The Confluence wiki service configuration is stored in our Puppet configuration.

We have made some modifications to the Puppet Manifest affecting the Module that
Confluence uses (cwiki_asf). Some code is being moved out from the module and
into a host specific YAML file. This will make it easier for future hosts to re-use the
module (such as an upgrade host currently awaiting these changes.)
A twitter notification will be posted 1 hour before.
A planned maintenance notice will be posted on status.apache.org.

If necessary we will make use this outage window to apply any OS updates and reboot
the host VM.

Actual downtime should be no more than 1 hour all being well.

An email about this will be sent to infrastructure@ after the service has resumed from the planned downtime.



Hot Blogs (today's hits)

Tag Cloud