Thanks for all feedback we will iterate on this feedback.
Here are some of the thoughts that went into the current proposal which
could help answer many of the questions.
1) What is the configuration API? The configuration API is split between
two interfaces, one for users and one for developers.
* ClusterManagementService(CMS) is our user interface:
- create(configElement, group...)
- delete(configElement, group...)
- update(configElement, group...)
- read(configElement, group....)
* ClusterConfigElement(CCE) is our developer's interface which abstracts
the underlying workflow. So each config element has to define:
- State (the configuration)
- How is the configuration applied to cache?
- How is the configuration persisted?
Splitting the interface into two, made CMS be lean with only 4 methods
rather than 4XN methods (where N is a number of configurable constructs eg:
region, gws, gwr etc and 4 one for each CRUD operations).
2) What's the communication channel?
We can use existing client-server and p2p channels to expose CMS and add
REST as a wrapper. I think this is redundant if we anyway want to expose
using REST.
3) What is user's workflow?
- get CMS from the cache (here CMS on the client or on the server is just a
client wrapper on REST, whereas on locator it is Java API)
- create a configuration element that needs to be applied
- invoke an action (CRUD) method on CMS
Sai
On Fri, May 25, 2018 at 9:07 AM Alexander Murmann <amurm...@pivotal.io>
wrote:
> 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 <jil...@pivotal.io> 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 <u...@apache.org> 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 <dsm...@pivotal.io> 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 <
>>>> sai_boorlaga...@apache.org> 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
>>
>
>
