You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Problem Statement

Currently, when developer wants to change the configuration of a cluster, say, create a region (or destroy an index, or update an async event queue) and have the change persisted in cluster configuration for incoming servers, there is no public api for him to do so. He will have to replicate the effort of the equivalent gfsh command to achieve the same effect. It would be nice if we can expose what these commands do to a public API.

 

Product Goals

 

The developer should be able to save their configuration to the Cluster Configuration Service without having to restart the servers.

Obtain the cluster config service from cache.

Pass config object to the cluster config service.

CRUD operations support for config objects.

User Goals

Create a more modular product to allow for easy extension and integration. The beneficiaries of this work are the developers working on different parts of the code such as Spring Data for Apache, Queries for Lucene index, storage for the JDBC connector, other Geode developers and anyone who wants to save settings to the Cluster Configuration Service.

What We Have Now:

From the current state of commands, It's not easy to extract a common interface for all the commands. And developers do not want to use gfsh command strings as a "make shift" api to call into the command. We are in need of a unified interface and a unified workflow for all the commands as well.

Proposal

Following the effort here, Public API for Retrieving/Updating Cluster Configuration, we already have a set of configuration objects derived from the cache xml schema. This would serve a common object that developers would use to configure the config instance first and then ask the cluster configuration service to persist it, either on the cache(create the real thing on an existing cache) or on the configuration service (persist the configuration itself). 

On the locator side, the configuration service framework will just handle the workflow. It's up to each individual ClusterCacheElement to implement how it needs to be persisted and applied. 

Pros and Cons:

Pros:

  1. a common interface to call either on the locator/server/client side.
  2. a common workflow to enforce behavior consistency.
  3. Modularized implementation. The configuration object needs to implement the addition interfaces in order to be used in this API. This allows us to add functionality gradually and per function groups.

Cons:

  1. Existing gfsh commands need to be refactored to use this API as well, otherwise we would have duplicate implementations.
  2. When refactoring gfsh commands, some commands' behavior will change if they want to strictly follow this workflow, unless we add additional APIs for specific configuration objects.


Project Milestones

Milestone for this project are implementation an extension to the new Public API.

  • No labels