software/theia: Disable frontend forwarding from resilient clone
Until now, the resilient clone (theia1
) also forwarded frontend requests from cloned embedded instances (e.g. ERP5) to the external master. This mirrored the request already sent from the main embedded instance in theia0
. But since theia0
and theia1
belong to the same instance tree, from the point of view of the external master those two requests are the same.
So every time the backup instance was processed (once a day), there was a tug-of-war on this shared frontend, were theia1
would briefly overwrite its parameters to redirect to the cloned embedded instance, before thei0
would reprocess its embedded instance and tug the shared frontend back to the original embedded instance.
To fix this, frontend forwarding is now disabled for theia1
. When the cloned embedded instance requests a frontend, the local proxy will now fall back to the harcoded default behavior of faking the frontend allocation by returning the original url. This allows the cloned embedded instance to instantiate normally while keeping it fully isolated.
I added a test that deploys a nested theia inside
theia0
, waits untiltheia1
is synced then checks that during processingtheia0
did forward the frontend requests andtheia1
did not.This is a bit delicate because the proxy database is cloned from
theia0
totheia1
before the cloned embedded instance is processed, so both versions contain the forwarded requests. Thankfully, every time a row is inserted the rowid changes, so by checking the rowids are identical we can be sure no forwarded frontend requests were inserted in the database after it was cloned.Using the rowids is so that the test will still work once slapos.core!423 (merged) is merged. Until then the rowids are actually unnecessary because the history of all insertions is (unintentionally) preserved, so if
theia1
did forward requests there would be more rows in the cloned database.Note that inspecting the "external master", i.e. the proxy of the test node, is unpractical: since that proxy does not forward frontend requests, it falls back to faking the frontend allocation, and this does not leave a trace in the proxy database either way. The only sign that this happened is in the logs, so this makes it unpractical to determine whether
theia1
did or did not forward frontend requests.added 1 commit
- 0a77588a - software/theia: Add test for frontend forwarding
added 1 commit
- 55bb808e - software/theia: Add test for frontend forwarding
added 1 commit
- 31e8fda2 - software/theia: Add test for frontend forwarding
added 20 commits
-
31e8fda2...2a28b3d4 - 18 commits from branch
nexedi:master
- 93d60f13 - software/theia: Disable frontend forwarding from resilient clone
- 6a268834 - software/theia: Add test for frontend forwarding
-
31e8fda2...2a28b3d4 - 18 commits from branch
mentioned in commit bdc6e1a7