Udo, Good point. Yes, actually the bulk of the design work is behind the interface point (currently set as REST). The doc might not reflect that after we've added a big section on how user/developer will interact with this API. The "Behind the Scene" section might address your concern of "all configuration logic for said Geode components and dependency logic in a single location" and the extensibility of it. One of the diagram talks about using JAXB object to represent a Geode component and and server side representation of that object needs to handle how to apply that configuration to an existing Cache or a configuration of the cache. After that Gfsh or the CMS will just manage the workflow of when/where these operations happen.
On Thu, May 24, 2018 at 5:04 PM, Udo Kohlmeyer <[email protected]> wrote: > 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]> 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]> 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/ >> > Cluster+Management+Service >> > >> > I would like to hear the feedback on the proposal. >> > >> > Sai >> > >> > > > > -- > Cheers > > Jinmei > > > -- Cheers Jinmei
