You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Sai Boorlagadda <sa...@apache.org> on 2018/05/24 18:57:15 UTC
[Proposal] CMS - cluster management service
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
Re: [Proposal] CMS - cluster management service
Posted by Sai Boorlagadda <sa...@apache.org>.
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 <am...@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 <ji...@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 <ud...@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 <ds...@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_boorlagadda@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
>>
>
>
Re: [Proposal] CMS - cluster management service
Posted by Sai Boorlagadda <sa...@apache.org>.
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 <am...@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 <ji...@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 <ud...@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 <ds...@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_boorlagadda@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
>>
>
>
Re: [Proposal] CMS - cluster management service
Posted by Alexander Murmann <am...@pivotal.io>.
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 <ji...@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 <ud...@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 <ds...@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_boorlagadda@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
>
Re: [Proposal] CMS - cluster management service
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <ud...@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 <ds...@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_boorlagadda@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
Re: [Proposal] CMS - cluster management service
Posted by Udo Kohlmeyer <ud...@apache.org>.
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 <dsmith@pivotal.io
> <ma...@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_boorlagadda@apache.org <ma...@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/
> <https://cwiki.apache.org/confluence/display/GEODE/>
> > Cluster+Management+Service
> >
> > I would like to hear the feedback on the proposal.
> >
> > Sai
> >
>
>
>
>
> --
> Cheers
>
> Jinmei
Re: [Proposal] CMS - cluster management service
Posted by Udo Kohlmeyer <ud...@apache.org>.
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 <dsmith@pivotal.io
> <ma...@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_boorlagadda@apache.org <ma...@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/
> <https://cwiki.apache.org/confluence/display/GEODE/>
> > Cluster+Management+Service
> >
> > I would like to hear the feedback on the proposal.
> >
> > Sai
> >
>
>
>
>
> --
> Cheers
>
> Jinmei
Re: [Proposal] CMS - cluster management service
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <ds...@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_boorlagadda@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
Re: [Proposal] CMS - cluster management service
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <ds...@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_boorlagadda@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
Re: [Proposal] CMS - cluster management service
Posted by Dan Smith <ds...@pivotal.io>.
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_boorlagadda@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
>
Re: [Proposal] CMS - cluster management service
Posted by Dan Smith <ds...@pivotal.io>.
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_boorlagadda@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
>