Standardize the use of scheduler name/type and checker name/type

[okJiang]

Target

• Use a unified naming convention for schedulers/checkers
• Standardize the concepts of name and type of scheduler and converge their usage

Naming summary

• xxxx_checker this underscore format only appears in the checker, scheduler does not. It is recommended to unify it into the format of xxxx-checker
• Xx-y-scheduler (schedulerName) and xx-yy (schedulerType) are unified into xx-y-scheduler. Reason
  • The interaction with users uses the former. If the latter is used, it will destroy the consistency of user usage or generate a lot of additional work (do a lot of converts) to maintain user consistency, increasing complexity
  • The former has more usage scenarios in the code than the latter
  • The former will be persistent, the latter will not
  • Unified with xxxx-checker
• Operator desc
  • Checker uses xxxx-checker.
  • Scheduler uses xxxx-yyyy. It will be replaced with xxxx-yyy-scheduler. It affects the printing of logs

checker

• xxxx_checker(checkerName)
• xxxx-checker(checkerType)

scheduler

• schedulerName is in the format of xx-y-scheduler
• schedulerType is in the format of xx-yy
• In addition, there are two special ones

    // HotRegionName is balance hot region scheduler name.
    HotRegionName = "balance-hot-region-scheduler"
    // HotRegionType is balance hot region scheduler type.
    HotRegionType          = "hot-region"
        // ScatterRangeType is scatter range scheduler type
    ScatterRangeType = "scatter-range"
    // ScatterRangeName is scatter range scheduler name
    ScatterRangeName = "scatter-range"

• xx-yy-scheduler(schedulerName)
• xx-yy(schedulerType)

Deep scheduler name/type

For schedulers, there is indeed a difference between name and type, but in the current code, these two are completely confused, making it difficult for readers to understand them. This section aims to completely distinguish them and give a clear definition. First

name

There are three ways to name a name

WithXxxxxxName

These three schedulers allow you to specify their names at creation time.

• balanceLeaderScheduler, not used yet
• balanceRegionScheduler, will specify the name as scatter-range-region
• balanceWitnessScheduler, will specify the name as scatter-range-leader

ScatterRange

Scatter-range-scheduler name is named by the key-range entered by the user, named scatter-range- {key-range} . Later changed to scatter-range-scheduler- {key-range}

Other

The names of other schedulers can be directly equivalent to type because they are constant

Name vs type

• Type can be directly understood as the types of schedulers we support.

var string2SchedulerType = map[string]CheckerSchedulerType{
    "balance-leader-scheduler":          BalanceLeaderScheduler,
    "balance-region-scheduler":          BalanceRegionScheduler,
    "balance-witness-scheduler":         BalanceWitnessScheduler,
    "evict-leader-scheduler":            EvictLeaderScheduler,
    "evict-slow-store-scheduler":        EvictSlowStoreScheduler,
    "evict-slow-trend-scheduler":        EvictSlowTrendScheduler,
    "grant-leader-scheduler":            GrantLeaderScheduler,
    "grant-hot-region-scheduler":        GrantHotRegionScheduler,
    "balance-hot-region-scheduler":      HotRegionScheduler,
    "random-merge-scheduler":            RandomMergeScheduler,
    "scatter-range-scheduler":           ScatterRangeScheduler,
    "shuffle-hot-region-scheduler":      ShuffleHotRegionScheduler,
    "shuffle-leader-scheduler":          ShuffleLeaderScheduler,
    "shuffle-region-scheduler":          ShuffleRegionScheduler,
    "split-bucket-scheduler":            SplitBucketScheduler,
    "transfer-witness-leader-scheduler": TransferWitnessLeaderScheduler,
    "label-scheduler":                   LabelScheduler,
}

• Name is the name of a scheduler at runtime, and it must be unique in the code execution. Because it is impossible to run two identical schedulers at the same time. So with this definition, it should be used in these places:
  • Stored in the scheduler config (storage). Each schedudler at runtime should have its own configuration.
  • The Controller will contain all runtime schedulers/scheduler-handles, and each scheduler will have a corresponding name.
  • The scope in the filter needs to use name, which also records the runtime state

Compatibility issues

• Keep the original monitoring and add the modified monitoring.
• schedulerConfig will save (xxxx-yyyy) schedulerType in PersistOptions, and then persist it to storage. It is necessary to find the form of schedulerType when reloading and then re-Set it to the form of xxxx-yyyy-scheduler to ensure compatibility.
• Scatter-range will change to scatter-range-scheduler , which needs to ensure compatibility and affect pd-ctl and http client. You need to keep the previous scatter-range command and use scatter-range-scheduler in the documentation (fortunately, there is no explanation of the scatter-range command in the pd-ctl documentation now - -)

Conclusions

After some offline discussions, here are some conclusions.

• xxxx_checker and xxxx-checker unified into xxxx-checker
• Xx-y-scheduler and xx-yy are unified into xx-y-scheduler.
• Standardize the use of scheduler name, use scheduler.Name to access scheduler name instead of global constant
• For scatter-range, keep the scatter-range command in API/pdctl and add scatter-range-scheduler command
• For schedulerConfig that needs to be persisted, convert to the old format to maintain compatibility
• For monitoring, it will be used as a filter rule_checker/replica_checker/merge_checker , temporarily converted from xxxx-checker to xxxx_checker when needed to maintain user experience compatibility. If it is determined that there is no compatibility problem, then change it
• Other monitoring will not be used as filters, but will only be grouped and will only affect the displayed name (some change from xx-yy to xx-yy-scheduler), but will not affect the displayed content. There are no compatibility issues

Code changes

ref #8316

There are too many code changes. After splitting PR, review them one by one and merge them into the feature branch, and then merge them into the master.

• [Done] All xxxxxName / xxxxxType are unified as XxxxChecker / XxxxScheduler , that is, xxxxx-checker / xxxxx-scheduler form
• [Done] Modify XxxxScheduler. GetName () to XxxxScheduler.Name () and use the latter to represent the semantics of SchedulerName
• [Done] Remove XxxxScheduler. GetType ()
• [Done] CheckSchedulerType to check if schedulerName is a supported schedulerType
• [Done] Convert schedulerName to schedulerType through ConvertSchedulerStr2Type
• [Done] Remove String () from filter, use XxxxChecker / XxxxScheduler uniformly
• [Done] Scatter-range will be converted to scatter-range-scheduler , which will affect pd-ctl and http-client
• TODO: scatter-range-scheduler Compatibility Makeover

Progress

• checker: use CheckerSchedulerType for checker  #8385
• scheduler: add scheduler type and move metrics file #8393
• scheduler: Replace the input parameter of AddScheduler with types.CheckerSchedulerType. #8416
• scheduler: GetType() returns types.CheckerSchedulerType directly #8440
• *: instead scheduler type string of types.CheckerSchedulerType #8485
• *: instead scheduler type string of types.CheckerSchedulerType #8485
• scheduler: extract storage operations to schedulerConfig interface #8515
• scheduler: remove old scheduler name #8516
• rename scatter-range to scatter-range-scheduler