search

SORMAS-Foundation / SORMAS-Project

SORMAS (Surveillance, Outbreak Response Management and Analysis System) is an early warning and management system to fight the spread of infectious diseases.
https://sormas.org
GNU General Public License v3.0
293 stars 142 forks source link

[S2S] Evaluate neccessary steps to safely deactivate S2S on an instance #10526

Closed SORMAS-JanBoehme closed 1 year ago

SORMAS-JanBoehme commented 2 years ago

Problem Description

As discussed earlier in our video chat we need to evaluate what the implications are when deactivating S2S on an instance where it has been running for some time.

The steps to deactivate S2S in my opinion are:

  1. Delete all cases and contacts that have been received as read-only from other instances (through the UI, performed by an admin user)
  2. Deactivate S2S feature and central sync on the instance
  3. Remove entry for instance from central ETCD
  4. Remove instance's certificate

Proposed Solution

Wait/Merge with work from #11399

Possible Alternatives

Additional Information

The open questions to be answered are:

  1. What happens when S2S is deactivated but an entity that has been shared with another instance is edited? Does it try to sync and fail? Does it not try to sync because the feature is deactivated? Would this have implications on the system's stability as a whole?
  2. What happens when another instance that still has S2S activated edits an entity that has been shared with the instance where S2S is now deactivated? It will probably try to sync but fail. What are the implications?

FYI: @JonasCir @SahaLinaPrueger

JonasCir commented 2 years ago

I would actually leave central infra sync in place, doesn't make sense to allow the GAs to mess up their infra data again :D

SahaLinaPrueger commented 1 year ago

NLI and I tested today the deactivation of S2S. The test protocol and the logs are attached.

From my point of view (the 'UI view') we can replace the first step as follows:

  1. The instance on which S2S will be deactivated has to revoke all outgoing pending requests AND has to accept or reject all incoming pending request (because of case 5, case 6 and case 7 in the test protocol).

AND if an instance wants to re-activate S2S we have to inform the instance, that yet shared requests with ownership will only be retroactively synced if the target system makes changes on the person/case/contact.

AND if an instance wants to deactivate S2S they have to deal with the point that they cannot see anymore the whole sharebox or share directory. So they cannot track if the case/contact was shared with/by another instance or not. Would be nice if we had an Export-function on the share directory to prevent this.

@JonasCir please check the logs and give feedback whether everything is OK there. Test Deactivate S2S.pdf

Logs for steps while S2S was de-activated: release-sormas-x-25102022-application.log release-sormas-x-25102022-syslog.log test-rki-25102022-application.log test-rki-25102022-syslogs.log

Logs for steps while S2S was re-activated: 2_release-sormas-x-25102022-application.log 2_release-sormas-x-25102022-syslog.log 2_test-rki-25102022-application.log 2_test-rki-25102022-syslog.log

JonasCir commented 1 year ago

@SahaLinaPrueger Just reach out to me when you are available. The attached logs are unfortunately empty if I download them.

SahaLinaPrueger commented 1 year ago

Logs for steps while S2S was de-activated: release-sormas-x-25102022-application.log release-sormas-x-25102022-syslog.log test-rki-25102022-application.log test-rki-25102022-syslogs.log

Logs for steps while S2S was re-activated:: 2_release-sormas-x-25102022-application.log 2_release-sormas-x-25102022-syslog.log 2_test-rki-25102022-application.log 2_test-rki-25102022-syslog.log

JonasCir commented 1 year ago
  1. Stop the instance and create backup
  2. The instance on which S2S will be deactivated has to revoke all outgoing pending requests AND has to accept or reject all incoming pending request (because of case 5, case 6 and case 7 in the test protocol).
  3. AND if an instance wants to re-activate S2S we have to inform the instance, that yet shared requests with ownership will only be retroactively synced if the target system makes changes on the person/case/contact.
  4. AND if an instance wants to deactivate S2S they have to deal with the point that they cannot see anymore the whole sharebox or share directory. So they cannot track if the case/contact was shared with/by another instance or not. Would be nice if we had an Export-function on the share directory to prevent this.
  5. Deactivate the S2S feature by commenting all relevant properties in sormas.properties: sormas2sormas.*, central.oidc.url
  6. Optional if GA wants to disable central infra sync: comment central.* I would strongly discourage this.
  7. Remove service descriptor for the removed instance from central ETCD
  8. Reset feature configuration table
  9. Remove client and client scope of the instance from central Keycloak
  10. shred the instance's key material
SahaLinaPrueger commented 1 year ago

As discussed with @JonasCir we want to repeat the deactivation and look how database behave if automatically deletion is involved and how the deactivated system behave for two days.

JonasCir commented 1 year ago

@nliakm This is my current list. Feel free to comment or add stuff in case I missed something. Currently, writing ansible roles etc. is out of scope, I really just want to focus on the "business steps" we need to do, operation is a different topic.

JonasCir commented 1 year ago

Going to move this to review in the Kanban now, if the next test run passes, I'm going to close this...

MartinWahnschaffe commented 1 year ago

@JonasCir We need to document this somewhere

JonasCir commented 1 year ago

I can put it into the document I am currently writing

MartinWahnschaffe commented 1 year ago

See https://github.com/hzi-braunschweig/SORMAS-Project/issues/11399

JonasCir commented 1 year ago

I just added this to a section in #https://github.com/hzi-braunschweig/SORMAS-Project/issues/11399