With setting value:

  1. only local data writes, returning a specific error to federation peers that it is in read-only mode and not accepting new comments, posts, likes, subscribes from peer servers.

  2. a federation-only mode where local users are not allowed to change their settings, delete their data, create new posts, create new comments, record votes, edit, etc.

  3. read-only mode site-wide, both local API users and federated peers not allowed to write data.

The second one would also be useful when a site wants to go offline and has a period of time it is ‘archived’ like GitHub archives projects.

I think upgrade instructions for new versions would have recommendation to set this on for a 5 minute period and do a shakedown read-only test of the site before throwing the switch to allow new data inserts into the PostgreSQL database backend.

Standard response codes issued to all peer servers and API clients as to the specific read-only nature of the instance so they can generate an appropriate message in their user interface.

I am making this recommendation based on the version 0.18.1 severe performance problems that Lemmy is having with 1 million comments in the database. To scale, it is essential that new versions can be released into production and rolled-back.

  • RoundSparrowOPM
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Nice to have variation of the idea…

    On both the API front-door and federation back-door, a simple stand-alone application (“dummy_lemmy_server”) that can be run that responds to all requests with the same response-code that the server is in read-only (really won’t even provide data) mode. Something to put in place during major server hardware changes/relocation and migration database updates.