commit 05357bef8bd0ffbda698b2753773c7d96ee3b35c
author Dariusz Luksza <dariusz.luksza@gmail.com> Fri Jan 05 21:38:29 2024 +0000
committer Gerrit Code Review <noreply-gerritcodereview@google.com> Fri Jan 05 21:38:29 2024 +0000
tree 043ca4f9e3b5b24eea7deb4c3f02a726bb909db4
parent e471c8e1aecd6a574472c4b72e11cf2980114d61

Update git submodules

* Update plugins/replication from branch 'master'
  to dc41fee03e9233503e92caea8dae4838e4003d20
  - Remove ReplicationConfigImpl constructor added for testing
    
    Clean up code after implementing external configuraiton extension point.
    Remove a helper constructor added to limit changes in tests.
    
    Change-Id: Ib89f7a264848aee4ead45d545fd77a0ae97852d1
    
  - Expose ApiModule with ReplicationConfigOverrides
    
    To ease working with `ReplicationConfigOverrides` expose them as
    _Cross-Plugin Communicaiton_ module (aka _ApiModule_). Consumers will
    now be able to put `replication.jar` together with their own custom
    configuration provider in `plugins/` directory and customize plugin
    configuration.
    
    It is also possible to mix _Cross-Plugin Communication_ with
    _libModule_. For this use case the `replication.jar` must be moved to
    `lib/` directory and `gerrit.installMoudle` configuration option added
    to `gerrit.config`.
    
    Bug: Issue 310510978
    Change-Id: Ib7a04eea503b221eae02cdeb393e3f727dda540f
    
  - Add support for overriding replication configuration
    
    It is a next step in the direction of modifying the replicationn
    configuraiton from an external source. Where the external source could
    be a git repository or third party configuration managemnet system.
    
    This adds a `ReplicationConfigOverrides` interface and a default bindng
    for `DynamicItem<ReplicationConfigOverrides`. The added interface is
    just an extension of `ConfigResource` as Guice was complaining about
    duplicated binding for `ConfigResource` when it was used in
    `DynamicItem`. Additinally `RepilcationConfigOverrides` conveys better
    its purpose.
    
    For now, the default implementation provides no overrides. As the
    location of overrides files is still to be decided.
    
    Finally, the `MergedConfigResource` will take both, the base
    configuraiton for the file system, and configured overrides and merge
    both JGit `Config` objects togehter.
    
    With this approach, an implementation of `ReplicationConfigOverrides`
    can provide a single confiuration option or the whole configuration
    file.
    
    Later we may consider, discarding some of the overrides, like
    `gerrit.autoReload`, as disabling that option will effecively prevent
    users from updating configuation.
    
    Change-Id: I2e401c05571180719df33a4a094fbb4ccfb39f23
    
  - Convert `FanoutReplicationConfig` to `FanoutConfigResource`
    
    With the introduction of `ConfigResource` we can simplify how the
    "fanout" configuration works and reduce the code complexity.
    
    The "fanout" replication configuration moves the `remote` sections from
    the `replication.config` file into the `replication/` directory with
    one-remote-per-file approach.
    
    What this effectively means, is the final config object provided by the
    "fanout" approach, is built not from a single file, but potentially
    from multiple files.
    
    This is one of the purposes of `ConfigResource`, to get the
    configuration object regardless of how or where it's stored.
    
    That's why, converting the `FanoutReplicationConfig` into
    `FanoutConfigResource` makes sense. It also simplifies the code, as
    `@MainReplicationConfig` is no longer needed.
    
    Change-Id: Ic6a5c5b8ab502a5e53d52a146d73b219563ee759
    
  - Add `ConfigResource` interface
    
    This is a first step for providing replication configuration from an
    external source. The `ConfigResource` bundles together JGit `Config`
    instance with its version.
    
    The future implementations can read the configuration from a Gerrit
    project or external systems like ZooKeeper.
    
    The idea here is to separate the configuration resource from
    configuration options. This way it is easier to manage the configruation
    externally and also provide layers of configuration like "git config"
    command does.
    
    On top of the `ConfigResource` we sill use the `ReplicationConfig` and
    `ReplicationFileBasedConfig` to access plugin configuraiton options. The
    auto-reloading mechanism is also reused.
    
    Change-Id: I77d205dce223e508bf4a06c5ff9da91444a87032
    
  - Extract `ReplicationConfigModule`
    
    Move configuration related bindings to a specialized
    `ReplicationConfigModule`. This hides implementation details like
    conditional bindings based on the configuration options.
    
    Additionally this will also limit the impact on the `pull-replication`
    plugin when we decide to move around configuration classes or add new
    configuration related functionality.
    
    Change-Id: I2fa409cdf19079a0c05a9b0612847bd2be2527f1