Provide a way to run a Plugin in a zone leader replica

[ikhoon]

Motivation:

When Central Dogma works on multiple IDC, we may need to run a Plugin in a specific zone due to network latency, firewall policy, or load balancing.

Modifications:

• Add PluginTarget.ZONE_LEADER_ONLY to run a Plugin in each zone leader.
• Add ZoneProvider interface to dynamically resolve a zone name.
• Allow setting zone via dogma.json and CentralDogmaBuilder.
  • If the value of zone starts with classpath:, the class is loaded and cast to ZoneProvider.
  • If the value starts with $, the value is read from the environment variable.
• Add onTakeZoneLeadership and onReleaseZoneLeadership to the methods and fields where onTakeLeadership and onReleaseLeadership were defined before.
  • /leader/{zone} is used to take the zone leadership.

Result:

You can now run a Plugin in a zone leader with the following:

• dogma.json

  {
     "zone": "my-zone" 
  }

• Plugin

  class ZoneLeaderPlugin implements Plugin {
  
    @Override
    public PluginTarget target() {
      return PluginTarget.ZONE_LEADER_ONLY;
    }
  }

[minwoox]

Basically looks great! Left a few suggestions. 😉

[minwoox]

Shouldn't this be in replication because zone is only used when replication is enabled?

[ikhoon]

I designed PluginTarget.ZONE_LEADER_ONLY to run with a standalone mode for the convenience of testing.

[minwoox]

Because this converts a value in the configuration file, how about using ConfigValueConverter?
I also had the plan to add classpath support in DefaultConfigValueConverter.

[ikhoon]

classpath seems useful. That said, I decided not to add classpath support but use a custom ConfigValueConverter to dynamically load a zone name.
It would take some time for me to design whether to call the function by convention such as one method with no-args or provide an API. Let me revisit it when I come to a conclusion.

[jrhee17]

Left a review on naming, but looks good 👍

[jrhee17]

I do think zone may be confusing for users since it seems like a generic field which handles multi-zone deployment, but only affects plugin behavior - especially since there hasn't been a notion of zone in central dogma before (only internally).

What do you think of naming this more specifically if you don't have plans to expand the functionality of this field?

e.g.
plugin-group-id/plugin-zone-id

Alternatively, I think just using groupId of the server itself may be clearer - I think it is possible to deduce it from the peerId once a zk server starts.

[ikhoon]

That's a good point. As you said, it's currently only used for plugins, but I didn't think the usage of it is limited to the plugins. It would also be useful to expose zone in the UI. When creating a mirroring job, I plan to take a zone to run. Textual information is better than groupId which is a number.

Additionally, we may allow creating repositories only in certain zones later, as cloud providers do.

[jrhee17]

By adding a coupling with zone, users won't be able to run plugins with arbitrary groups: i.e. run pluginA for ZoneA,ZoneB, run pluginB for ZoneC.

Having said this, I agree it's probably fine to proceed as-is since we haven't had requirements for this kind of use-case yet and we can always add a new Plugin type.

Textual information is better than groupId which is a number.

Sounds fine, but when developing this field further I think it may still be useful if the relationship between groupId and zone is better defined. (Perhaps we can maintain an internal mapping of zone <-> groupId if only numbers are allowed)

[ikhoon]

Sounds fine, but when developing this field further I think it may still be useful if the relationship between groupId and zone is better defined. (Perhaps we can maintain an internal mapping of zone <-> groupId if only numbers are allowed)

I will think about this part further while working on mirroring. I need to change the configuration format to take all available zones to expose as a select box in the following PR.
For example:

zone: {
  currentZone: "ZoneA",
  allZones: ["ZoneA", "ZoneB", "ZoneC"]
}

[minwoox]

Looks great! 👍 👍 👍