I am sharing some concerns that are similar to Udo's. I was most surprised by the first diagram. I intuitively would have expected the Java API to be a shared interface that's the same on clients, servers and locators. The implementation then would in some cases call out via remote API to the locator (or wherever we might decide to do the heavy lifting in the future) or in other cases make the changes right there. As someone using the interface I wouldn't have to care which one happens.
I think what makes this first diagram concerning is that the Cluster management Service is the REST API and gets referenced by the Java API. I think we all want to make sure that we don't make the same mistake as we did before where we coupled a way of exposing functionality to the business logic. I'd feel better if it was more obvious in the behind the scenes section that the REST API is treated just as one possible adapter to calling the actual implementation that does the heavy lifting. it's probably a good approach though to first focus on what we are trying to accomplish from a user perspective before the actual implementation gets architected. On Thu, May 24, 2018 at 6:30 PM, Jinmei Liao <[email protected]> wrote: > 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 >
