[Proposal] CMS - cluster management service

[Sai Boorlagadda]

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

Fixed version as 1.8

[Nabarun Nag]

Hi Geode Community,

If you are committing any fix to the Apache Geode develop branch only,
please mark the the fixed version as 1.8 in the respective JIRA ticket

Regards
Nabarun Nag

Re: [Proposal] CMS - cluster management service

[Dan Smith]

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
>

Re: [Proposal] CMS - cluster management service

[Jinmei Liao]

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  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

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #927 was SUCCESSFUL (with 2406 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #927 was successful.
---
Scheduled
2408 tests in total.

https://build.spring.io/browse/SGF-NAG-927/





--
This message is automatically generated by Atlassian Bamboo

PR: Configure Spotless not to join already-wrapped lines

[Dale Emery]

Hi all,

I've submitted a PR to configure Spotless to refrain from joining 
already-wrapped lines:
https://github.com/apache/geode/pull/1994 


My main motivation was to allow formatting method chains with one method per 
line (such as in long Stream pipelines, Mock configurations, and AssertJ 
assertions) when that would make the code easier to understand.

The change in my PR goes further than that. It causes Spotless not to join any 
lines if they are already shorter than the line length limit. I could not find 
an easy way to prevent joining lines only in method chains.

Comments?

Dale

—
Dale Emery
dem...@pivotal.io