Change Details

As a tentative FOSDEM gift, it would be nice if we could open up our API to the world as a reveal. We need to make very sure that we don't get our pants caught on fire as we do it: we must avoid having our infrastructure torn down by the load. This meta task tracks the steps we need to take to be able to do this (deadline: Monday 30 January) [ ] (critical) create a read-only replica database [ ] (critical) implement rate limiting for anonymous access to the API [ ] (normal) token-based user authentication and rate-limiting for access to the API [ ] (normal) split moma in two virtual machines: one for the scheduler and associated stuff (rabbitmq) and one for the web ui While opening up the API for unauthenticated requests should not be an issue if we have a second database for read-only access, we should ramp up the load by allowing only heavily rate-limited API access at first, rather than open it all up and see it explode mid-flight. Provisions for authenticated access will allow us to give special rate limits to the people that need it, and be able to finely control it. This is not critical to have by FOSDEM, but we should be ready to provide it ASAP anyway. Might as well do that while we're adding the rate-limiting stuff. Splitting the scheduling and the web ui should have been done long ago but is now easy as pie as we have another hypervisor, it just needs the work to be done.

It's about time we open up our (HTTP-, JSON-based) API to the world. We need to make very sure that we don't get our pants caught on fire as we do it: we must avoid having our infrastructure torn down by the load. This meta task tracks the steps we need to take to be able to do this. [ ] (critical) create a read-only replica database [ ] (critical) implement rate limiting for anonymous access to the API [ ] (normal) token-based user authentication and rate-limiting for access to the API [ ] (normal) split moma in two virtual machines: one for the scheduler and associated stuff (rabbitmq) and one for the web ui While opening up the API for unauthenticated requests should not be an issue if we have a second database for read-only access, we should ramp up the load by allowing only heavily rate-limited API access at first, rather than open it all up and see it explode mid-flight. Provisions for authenticated access will allow us to give special rate limits to the people that need it, and be able to finely control it. This is not critical to have in the beginning, but we should be ready to provide it ASAP anyway. Might as well do that while we're adding the rate-limiting stuff. Splitting the scheduling and the Web UI should have been done long ago but is now easy as pie as we have another hypervisor, it just needs the work to be done.

As a tentative FOSDEM giftIt's about time we open up our (HTTP-, it would be nice if we could open up ourJSON-based) API to the world as a reveal. We need to make very sure that we don't get our pants caught on fire as we do it: we must avoid having our infrastructure torn down by the load. This meta task tracks the steps we need to take to be able to do this (deadline: Monday 30 January). [ ] (critical) create a read-only replica database [ ] (critical) implement rate limiting for anonymous access to the API [ ] (normal) token-based user authentication and rate-limiting for access to the API [ ] (normal) split moma in two virtual machines: one for the scheduler and associated stuff (rabbitmq) and one for the web ui While opening up the API for unauthenticated requests should not be an issue if we have a second database for read-only access, we should ramp up the load by allowing only heavily rate-limited API access at first, rather than open it all up and see it explode mid-flight. Provisions for authenticated access will allow us to give special rate limits to the people that need it, and be able to finely control it. This is not critical to have by FOSDEMin the beginning, but we should be ready to provide it ASAP anyway. Might as well do that while we're adding the rate-limiting stuff. Splitting the scheduling and the web uiWeb UI should have been done long ago but is now easy as pie as we have another hypervisor, it just needs the work to be done.