Arvados

21124-max-rails-reqs @ 2966d83fa4e18eb62d1bbb1c9a0c39d9d845112f -- developer-run-tests: #3875

21124-max-rails-reqs @ a12de3eeb2f75458120357ed520bb511242104bd -- developer-run-tests: #3876

• All agreed upon points are implemented / addressed.
  • I went with the name MaxConcurrentRailsRequests
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • N/A
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • ✅
• Documentation has been updated.
  • ✅ added upgrade note (looks like we added an upgrade note when changing the default from unlimited to 64, but forgot to add a note when changing the default to 8, oops)
• Behaves appropriately at the intended scale (describe intended scale).
  • should be what we intended to happen in #20680.
• Considered backwards and forwards compatibility issues between client and server.
  • N/A
• Follows our coding standards and GUI style guidelines.
  • ✅

• I think this limitation needs to be clarified at least on the config file reference, with the additional comment that API.MaxConcurrentRequests applies also to other arvados services.
• Also, I'm thinking that capping the controller MaxReq config to whatever Rails has (default 8 ) may still cause issues, as the Log API goes through controller, wdyt?

If my second comment above is a non-issue, then it LGTM.

Lucas Di Pentima wrote in #note-7:

• I think this limitation needs to be clarified at least on the config file reference, with the additional comment that API.MaxConcurrentRequests applies also to other arvados services.

Good point, added.

• Also, I'm thinking that capping the controller MaxReq config to whatever Rails has (default 8 ) may still cause issues, as the Log API goes through controller, wdyt?

I think this is fine/desirable -- "post logs" requests are automatically de-prioritized, and rejected if they exceed LogCreateRequestFraction.