[jira] [Comment Edited] (IGNITE-18093) Introduce distribution zone manager for the purposes of zones configuration

["Vyacheslav Koptilin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637685#comment-17637685 ] 

Vyacheslav Koptilin edited comment on IGNITE-18093 at 11/24/22 11:16 AM:
-------------------------------------------------------------------------

Hello [~Sergey Uttsel],

In general, the proposed change looks good to me. I left a few comments on your pull request. Please take a look.


was (Author: slava.koptilin):
Hello [~Sergey Uttsel],

In genera, the proposed change looks good to me. I left a few comments on your pull request. Please take a look.

> Introduce distribution zone manager for the purposes of zones configuration
> ---------------------------------------------------------------------------
>
>                 Key: IGNITE-18093
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18093
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Assignee: Sergey Uttsel
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> h3. Motivation
> Distribution zones manager is an ignite component that is responsible for both zones configuration(create/update/drop) and dataNodes calculation that is triggered by corresponding topology and zone modification events.
> Within the scope of current ticket it's expected that DistributionZoneManager will be introduced with an internal API to create, drop and alter distribution zones.
> h3. Definition of Done
>  * New ignite component DistributionZoneManager is introduced.
>  * It is inlined into ignite node start/stop flow.
>  * It's possible to create/alter/drop distribution zone with the help of ignite internal api that technically leads to cluster configuration changes.
> h3. Implementation Notes
> 1. First of all we should introduce new root zones configuration schema:
> {code:java}
> @ConfigurationRoot(rootName = "zone", type = ConfigurationType.DISTRIBUTED)
> public class DistributionZonesConfigurationSchema {
> /** Global integer id counter. Used as an auto-increment counter to generate integer identifiers for distribution zone. */
> @Value(hasDefault = true)
> public int globalIdCounter = 0;
>  
> /** List of configured distribution zones. */
> @NamedConfigValue
> public DistributionZoneConfigurationSchema distributionZones;
> }{code}
> and zone configuration itself:
> {code:java}
> /**
>  * Distribution zone configuration schema class.
>  */
> @Config
> public class DistributionZoneConfigurationSchema {
>     /** Zone name. */
>     @InjectedName
>     public String name;
>     /** Integer zone id. */
>     @Immutable
>     @Range(min = 1)
>     @Value(hasDefault = true)
>     public int zoneId = 1;
>     public int dataNodesAutoAdjustScaleUp;
>     public int dataNodesAutoAdjustScaleDown;
>     public int dataNodesAutoAdjust;
> } {code}
> Filter and affinity function type will be added to configuration later.
> 2. It's also required to introduce DistributionZoneManager as an IgniteComponent that should be started and stopped during node start and stop flow. The proper place to insert distributionZoneManager.start() is somewhere after clusterCfgMgr.start().
> 3. DistributionZoneManager should expose (as in internal API) methods to create alter and drop distribution zones.
> 4. Aforementioned create/alter/dropZone API should be available as part of Ignite @TestOnly internal api.
> 5. Internally all that methods should call update configuration closures. 
> 6. The only interesting part here is input data and drop validations. 
>  * In case of drop we should check whether there are tables binded to given zone. Let's say that CASCADE is not supported for now.
>  * Zone name should be checked for uniqueness. Let's ask SE teem about proper way of doing such checks, maybe there's an annotation that will help.
>  * Neither scaleUp or scaleDown are compatible with common auto adjust, so we should complete create result future (yep it's async) exceptionally if user specifies both (scaleUp || scaleDown) and common auto adjust. In case of alter proposed property should override non-compatible ones. 
>  * All-in-all some explicit validation, some configuration validators (see @TableValidator) and  tests are expected.
>  7. Lot's of unit tests are expected to be written, that will check that distibutionZoneManager.create()/update()/drop() is either returns future completed exceptionally with proper exception or actually change the configuration.
> 8. Please pay attention, that within given ticket its' not expected for partitions and replicas to be moved inside Zones. Let it still be tables for now. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)