This might just be biased talking, but I have always believe that an API
should be designed to be technology agnostic. Thus if you want to design
the new CMS api, don't muddy the water with REST or JSON, but rather
focus on intent, maintainability, versioning, extend-ability andÂ
simplicity.
The point is that this API should contain all configuration logic for
said Geode components and dependency logic in a single location.
Currently GFSH is too smart and contains knowledge about dependencies
and components, that would have to be duplicated in every endpoint
implementation.
I would start with removing the notion of clustering, as I believe
starting with a clean configuration API would be more beneficial.
Exposing a mechanism to store and share configuration between cluster
members is a function, which realistically could be handled in many
different ways. But providing extension points for this, is hugely
important.
Once the API is deemed correct, translating said API to technology of
choice, becomes simple. i.e exposing the API as a REST endpoint, or
consuming XML document or even GFSH. but realistically GFSH could become
a dumb client that could submit all commands to the Configuration REST API.
In addition to the new cleaner configuration API, there is a requirement
that for every said service endpoint, a contract exists. Describing
behaviors and expected behavior wrt. many inputs and expected outputs.
Also I would love to see some thought around how to add new component /
module configurations without having to do major surgery. How can
community members add components to the system without having to
understand every aspect of the codebase. Can there be an SPI or API than
can be extended/implemented that is discovered at startup time, adding
new functionality without requiring a completely new build of the product.
--Udo
On 5/24/18 13:28, Jinmei Liao wrote:
We haven't pinned down the exact java api on how client/server will
interact with this rest service available on the locator. I would
image a java api that would wrap the rest service call will be in
place. It would require the caller to provide the endpoint and the
necessary credentials and ssl configurations in order to connect.
On Thu, May 24, 2018 at 1:15 PM, Dan Smith <[email protected]
<mailto:[email protected]>> wrote:
Hi Sai,
+1 for making the cluster configuration API public. This looks great!
One question I have is about how the Java API is supposed to work.
You are
saying that the clients and servers will not send cluster
configuration
messages over their existing channels, but will instead connect to
this
admin REST endpoint. How do the clients and servers discover that
endpoint
and how do they make sure they have the right security certificates to
connect, etc.? It seems like this will require additional
configuration on
the clients and servers so they can connect to this endpoint?
-Dan
On Thu, May 24, 2018 at 11:57 AM, Sai Boorlagadda <
[email protected] <mailto:[email protected]>> wrote:
> Hello,
>
> Updating configuration of Geode clusters involves a workflow and is
> currently only exposed through 'gfsh commands'. Proposing a new
service/API
> to manage Geode clusters in which the underlying workflow is
accessible
> through an API.
>
> https://cwiki.apache.org/confluence/display/GEODE/
<https://cwiki.apache.org/confluence/display/GEODE/>
> Cluster+Management+Service
>
> I would like to hear the feedback on the proposal.
>
> Sai
>
--
Cheers
Jinmei
