[
https://issues.apache.org/jira/browse/IGNITE-23636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-23636:
---------------------------------
Description:
h3. Motivation
Currently {{DisasterRecoveryManager}} is placed in table module. For the
purpose of the
[IEP-131|https://cwiki.apache.org/confluence/display/IGNITE/IEP-131%3A+Partition+Majority+Unavailability+Handling],
{{DisasterRecoveryManager#resetPartitions}} must be available from
{{DistributionZoneManager}}, but {{DisasterRecoveryManager}} depends on
{{DisasterRecoveryManager}}, but, worst of all, depends on {{TableManager}}.
We need to decide how we plan to refactor {{DisasterRecoveryManager}} so it
could be possible to use {{DisasterRecoveryManager#resetPartitions}} in
{{DistributionZoneManager}}
h3. Implementation details
We need to preserve logic from {{DisasterRecoveryManager#resetPartitions}}
which uses requests with {{operationIds}}, {{RECOVERY_TRIGGER_KEY}} and writing
such requests to MS, and also all logic with setting force pending
h3. Definition of done
We have a plan of a refactoring, so it is possible to use
{{DisasterRecoveryManager#resetPartitions}} in {{DistributionZoneManager}}, and
all logic from this method is preserved without any redundant code duplication.
As a result, ticket for the development must be created.
was:
h3. Motivation
Currently {{DisasterRecoveryManager}} is placed in table module. For the
purpose of the
[IEP-131|https://cwiki.apache.org/confluence/display/IGNITE/IEP-131%3A+Partition+Majority+Unavailability+Handling],
{{DisasterRecoveryManager#resetPartitions}} must be available from
{{DistributionZoneManager}}, but {{DisasterRecoveryManager}} depends on
{{DisasterRecoveryManager}}, but, worst of all, depends on {{TableManager}}.
We need to decide how we plan to refactor {{DisasterRecoveryManager}} so it
could be possible to use {{DisasterRecoveryManager#resetPartitions}} in
{{DistributionZoneManager}}
h3. Implementation details
We need to preserve logic from {{DisasterRecoveryManager#resetPartitions}}
which uses requests with {{operationIds}}, {{RECOVERY_TRIGGER_KEY}} and writing
such requests to MS, and also all logic with setting force pending
h3. Definition of done
We have a plan of a refactoring, so it is possible to use
{{DisasterRecoveryManager#resetPartitions}} in {{DistributionZoneManager}}, and
all logic from this method is preserved without any redundant code duplication.
> Investigate refactoring of DisasterRecoveryManager
> --------------------------------------------------
>
> Key: IGNITE-23636
> URL: https://issues.apache.org/jira/browse/IGNITE-23636
> Project: Ignite
> Issue Type: Task
> Reporter: Mirza Aliev
> Assignee: Mirza Aliev
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Currently {{DisasterRecoveryManager}} is placed in table module. For the
> purpose of the
> [IEP-131|https://cwiki.apache.org/confluence/display/IGNITE/IEP-131%3A+Partition+Majority+Unavailability+Handling],
> {{DisasterRecoveryManager#resetPartitions}} must be available from
> {{DistributionZoneManager}}, but {{DisasterRecoveryManager}} depends on
> {{DisasterRecoveryManager}}, but, worst of all, depends on {{TableManager}}.
> We need to decide how we plan to refactor {{DisasterRecoveryManager}} so it
> could be possible to use {{DisasterRecoveryManager#resetPartitions}} in
> {{DistributionZoneManager}}
> h3. Implementation details
> We need to preserve logic from {{DisasterRecoveryManager#resetPartitions}}
> which uses requests with {{operationIds}}, {{RECOVERY_TRIGGER_KEY}} and
> writing such requests to MS, and also all logic with setting force pending
> h3. Definition of done
> We have a plan of a refactoring, so it is possible to use
> {{DisasterRecoveryManager#resetPartitions}} in {{DistributionZoneManager}},
> and all logic from this method is preserved without any redundant code
> duplication. As a result, ticket for the development must be created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
