Move membership code to a separate gradle sub-project
Superscript Authors: Jens Deppe, Patrick Johnson
Status: Discussion
Superseded by: N/A
Related: N/A
Problem
Geode currently has a hard dependency on Spring libraries as a result of gfsh
being developed against the spring-shell library.
We would like to extract gfsh and related cli code into a separate module such that Geode can be run without gfsh as part of the core if so desired. This decoupling will have various benefits:
- Removal of Spring dependencies from Geode core.
- Clearer understanding of which components rely on Spring.
- Clear separation of various generations of admin frameworks. As the newer Cluster Configuration Management functionality reaches maturity, users will be able to easily chose which functionality they wish to include.
Anti-Goals
- It is not a goal to provide a standalone gfsh utility
Solution
We will create a new gradle subproject called geode-gfsh-cli
. Ideally, all of the code in the org.apache.geode.management.internal.cli
package and related unit tests, will be moved out of geode-core and into geode-gfsh-cli. geode-gfsh-cli will have a dependency on geode-core.
JMX management functionality will be unaffected except for the ability to execute gfsh commands via the MemberMXBean.processCommand
method.
Changes and Additions to Interfaces
This proposal does not add or remove any public API.
A new CacheService will be added called CommandProcessor
which will enable the MemberMXBean.processCommand functionality (and thus enable gfsh capabilities).
The current mechanism to detect commands will not be changed, however the functionality will also be moved into the new module. Currently this involves scanning the classpath for classes implementing the org.springframework.shell.core.CommandMarker interface. Any user-created gfsh commands will need to depend on the new geode-gfsh-cli module.
Initial investigation has highlighted the need for at least the following changes:
RebalanceCommand
(a gfsh command which will need to be moved into the new package) is directly coupled toRebalanceCommandOperation
which is part of the new Cluster Configuration Management service.RebalanceCommand
will need to be refactored to remove the coupling.CliStrings
contains many constants which are used in various places throughout the management code. Our initial thought is that all cli-specific strings (ex. command help strings) will remain in this class and be moved into the new module and any common strings will be moved into a class in geode-core.CliUtils
contains various static methods which are mostly helper methods to ease executing functions and discovering members. Our initial though is that commonly useful methods will be moved into a newManagementUtils
class and the gfsh-dependent functions will remain inCliUtils
and be moved into the new package.
Performance Impact
There is no expected performance impact
Backwards Compatibility and Upgrade Path
These changes will maintain backwards compatibility with rolling upgrades.
This change will introduce a new optional geode-gfsh-cli maven artifact. Users building a classpath with maven/gradle/etc. will need to explicitly include this artifact if they wish to use gfsh commands.
Prior Art
There have been multiple proposals to make geode more modular - Geode Modularization Proposal (work in progress), Proposal for Geode Modularization. This proposal can be considered an incremental step in that direction.
FAQ
Q: Why not create a standalone gfsh utility?
A: A proof-of-concept, using a Spring Boot jar approach, for such a thing has been created. It requires bundling all of Geode dependencies, including war files, into a single jar resulting in a ~120MB artifact. This proposal does not preclude ever doing that, but it is not a current goal.
Errata
What are minor adjustments that had to be made to the proposal since it was approved?