Public Sequencer: Add automation to revoke ParticipantSynchronizerPermission based on ValidatorUnpermision. Extend integration test to to check both temporary revocation and permanent revocation - #6953
Conversation
…mission based on ValidatorUnpermision. Extend integration test to to check both temporary revocation and permanent revocation [ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
| val svParty = sv.getDsoInfo().svParty | ||
| val dsoRules = sv.appState.dsoStore.getDsoRules().futureValue | ||
|
|
||
| clue(s"${sv.participantClient.name} votes for UnpermissionValidator(revoked=$revoked)") { |
There was a problem hiding this comment.
how do I repermission them after this?
There was a problem hiding this comment.
Repermission is automatic if it is loginAfter based ValidatorUnpermission. Validator will get PERMISSIONED_DENIED until loginAfter, but then will work normally
Repermission with revoke based ValidatorUnpermission is more subtle, and needs more work, IMO
-
Validator X is revoked permeently, and SVs don't want it ever again. However, if someone buys traffic for X, then
GrantValidatorPermissionTriggerwill grant topology again, and hence bypass the unpermissioning. For this, we need to updateGrantValidatorPermissionTriggerto not grant topology, if there is a matchingValidatorUnpermission -
Allow rejoining after permenent revocation - to implement this we will need another seperate vote action where SVs vote to archive
ValidatorUnpermissioncontract. Only then someone can buy member traffic to submit topology from SV.
And anything else you have in mind for repermission?
There was a problem hiding this comment.
@moritzkiefer-da
Also, to simulate Repermission after loginAfter based ValidatorUnpermission, we need to add a TimeBased(simulated time)Integration Test. should we?
There was a problem hiding this comment.
Validator X is revoked permeently, and SVs don't want it ever again.
I don't think that is gonna fly. In some cases, the SVs just want to say "unpermission this node" without thinking about a time but maybe later change their mind. You can argue they shoudl set loginAfter to very far in the future but that seems like a mess to me. I guess maybe you can hide it in the UI but I'd say if we do have the option to fully revoke we also need to have the option to revert that.
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
moritzkiefer-da
left a comment
moritzkiefer-da
left a comment
There was a problem hiding this comment.
thanks, I think we'll need a bit more work for repermissioning but let's do that in another pr.
| val svParty = sv.getDsoInfo().svParty | ||
| val dsoRules = sv.appState.dsoStore.getDsoRules().futureValue | ||
|
|
||
| clue(s"${sv.participantClient.name} votes for UnpermissionValidator(revoked=$revoked)") { |
There was a problem hiding this comment.
Validator X is revoked permeently, and SVs don't want it ever again.
I don't think that is gonna fly. In some cases, the SVs just want to say "unpermission this node" without thinking about a time but maybe later change their mind. You can argue they shoudl set loginAfter to very far in the future but that seems like a mess to me. I guess maybe you can hide it in the UI but I'd say if we do have the option to fully revoke we also need to have the option to revert that.
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
[static] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
c733944
into
feature-public-sequencer-and-scan
2 participants
Fix #6938