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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #726 was successful.
---
Scheduled
2189 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Removing the old Authenticator/AccessControl interfaces

[Michael Stolz]

Yep. That's the normal path.

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771

On Mon, Oct 30, 2017 at 7:19 PM, Mark Bretl  wrote:

> If we are talking about the following:
> https://github.com/apache/geode/blob/develop/geode-core/
> src/main/java/org/apache/geode/security/Authenticator.java
> https://github.com/apache/geode/blob/develop/geode-core/
> src/main/java/org/apache/geode/security/AccessControl.java
>
> They are both marked '@deprecated since Geode 1.0' which I interpret to
> mean they were deprecated in Geode 1.0 and need to stay until 2.0, if we
> keep with semver.
>
> --Mark
>
>
>
> On Mon, Oct 30, 2017 at 3:55 PM, Jinmei Liao  wrote:
>
> > Yes, it's deprecated in 1.0.
> >
> > On Mon, Oct 30, 2017 at 3:39 PM, Dan Smith  wrote:
> >
> > > Are you saying these interfaces were already deprecated in 1.0? If so,
> > then
> > > I think we can remove them. If they have been deprecated after 1.0, I
> > think
> > > we have to wait until 2.0 to remove them.
> > >
> > > -Dan
> > >
> > > On Mon, Oct 30, 2017 at 1:18 PM, Jinmei Liao 
> wrote:
> > >
> > > > The old security framework, basically Authentcator/AccessControl
> > > interfaces
> > > > and the usage of them inside GEODE is deprecated since 1.0. I am
> > > wondering
> > > > since 1.3 is out already, can we start removing these interfaces and
> > > > usages? It would enable of deleting bunch of unmanageable tests.
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [ANNOUNCE] Apache Geode 1.3.0

[John Blum]

Congrats!

On Tue, Oct 31, 2017 at 10:22 AM, Swapnil Bawaskar 
wrote:

> The Apache Geode community is pleased to announce the availability
> of Apache Geode 1.3.0.
>
> Apache Geode is a data management platform that provides a database-like
> consistency model, reliable transaction processing and a shared-nothing
> architecture to maintain very low latency performance with high concurrency
> processing.
>
> Geode 1.3.0 contains a number of improvements and bug fixes.  This release
> includes finer grained security and ability to snapshot multiple regions
> simultaneously. Users are encouraged to upgrade to the latest release.
>
> For the full list of changes please review the release notes:
> https://cwiki.apache.org/confluence/display/GEODE/
> Release+Notes#ReleaseNotes-1.3.0
>
> The release artifacts can be downloaded from the project website:
> http://geode.apache.org/releases/
>
> The release documentation is available at:
> http://geode.apache.org/docs/guide/13/about_geode.html
>
> We would like to thank all the contributors that made the release possible.
>
> Regards,
> Swapnil Bawaskar on behalf of the Apache Geode team
>



-- 
-John
john.blum10101 (skype)

[ANNOUNCE] Apache Geode 1.3.0

[Swapnil Bawaskar]

The Apache Geode community is pleased to announce the availability
of Apache Geode 1.3.0.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.3.0 contains a number of improvements and bug fixes.  This release
includes finer grained security and ability to snapshot multiple regions
simultaneously. Users are encouraged to upgrade to the latest release.

For the full list of changes please review the release notes:

https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.3.0

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/13/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Swapnil Bawaskar on behalf of the Apache Geode team

Broken: apache/geode#4597 (develop - 19e5f8c)

[Travis CI]

Build Update for apache/geode
-

Build: #4597
Status: Broken

Duration: 15 minutes and 1 second
Commit: 19e5f8c (develop)
Author: jinmeiliao
Message: GEODE-3539: Consolidate CliUtil and DataCommandUtils, DataCommandsUtil 
(#992)

* GEODE-3539: Consolidate CliUtil and DataCommandUtils, DataCommandsUtil

* remove DataCommandsUtil
* move method from DataCommandUtils to CliUtil if applicable.
* move moethds from DataCommandUtils to individual command if only used by one 
command

View the changeset: 
https://github.com/apache/geode/compare/fd907a00ae1c...19e5f8ce4995

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/295383298?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: Geode Nightly issue

[Anthony Baker]

I pushed a fix to restore the releaseType.

> On Oct 31, 2017, at 9:45 AM, Dick Cavender  wrote:
> 
> It appears that Swap's merge of release/1.3 branch to develop yesterday
> introduced the problem seen in last night's nightly build. We have a fix to
> commit shortly.
> 
> -Dick

Geode Nightly issue

[Dick Cavender]

It appears that Swap's merge of release/1.3 branch to develop yesterday
introduced the problem seen in last night's nightly build. We have a fix to
commit shortly.

-Dick

Re: Consistent results from gfsh commands

[Udo Kohlmeyer]

+1 for consistency.
I'm just curious how this would be displayed a cluster has many nodes.

On Tue, Oct 31, 2017 at 7:59 AM, Jens Deppe  wrote:

> Hi,
>
> I've noticed that various commands, that execute on multiple members,
> return either tabulated results (one line per member - for example
> CreateRegionCommand) or a single pass/fail line. In the latter case it’s
> possible that information would get lost. For example if a command fails on
> multiple members (but not all) then the user would not have complete
> insight into where the failure occurred.
>
> I'd like to propose that if a command executes on multiple members it
> should always return and display all the results. Alternatively, if the
> command succeeds then it should simply indicate success, however if it
> fails (even partially) it should return a full list of each member and the
> result of the command on each of the members.
>
> Thoughts; comments?
>
> --Jens
>



-- 
Kindest Regards
-
*Udo Kohlmeyer* | *Pivotal*
ukohlme...@pivotal.io

www.pivotal.io

Re: Consistent results from gfsh commands

[Juan José Ramos]

+1, we should provide the user with the full details about what happened
when there was at least one failure.
Following this line of thought, and considering the cluster configuration
service, what should the commands do when the operation fails on at least
one member?. Persist the changes no matter what?, don't persist the
changes?, it depends on the operation (create region vs create index)?, add
a new flag to *gfsh* and let the user decide?.
Cheers.

On Tue, Oct 31, 2017 at 2:59 PM, Jens Deppe  wrote:

> Hi,
>
> I've noticed that various commands, that execute on multiple members,
> return either tabulated results (one line per member - for example
> CreateRegionCommand) or a single pass/fail line. In the latter case it’s
> possible that information would get lost. For example if a command fails on
> multiple members (but not all) then the user would not have complete
> insight into where the failure occurred.
>
> I'd like to propose that if a command executes on multiple members it
> should always return and display all the results. Alternatively, if the
> command succeeds then it should simply indicate success, however if it
> fails (even partially) it should return a full list of each member and the
> result of the command on each of the members.
>
> Thoughts; comments?
>
> --Jens
>



-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Consistent results from gfsh commands

[Jinmei Liao]

+1 for consistency.

There is one caveat: destroy region command, e.g. is executing the function
on all members that have the region, but the function is calling a
distributed method (region.destroy()) which will be propagated to other
members. So if the "destroy" is successful on one member, the command is
deemed successful. How do we handle this case? Pick only one member to
execute the command or still iterate on all members, but report truthfully
on what happened on each member?

On Tue, Oct 31, 2017 at 8:29 AM, Michael William Dodge 
wrote:

> +1 for consistency!
>
> Sarge
>
> > On 31 Oct, 2017, at 07:59, Jens Deppe  wrote:
> >
> > Hi,
> >
> > I've noticed that various commands, that execute on multiple members,
> > return either tabulated results (one line per member - for example
> > CreateRegionCommand) or a single pass/fail line. In the latter case it’s
> > possible that information would get lost. For example if a command fails
> on
> > multiple members (but not all) then the user would not have complete
> > insight into where the failure occurred.
> >
> > I'd like to propose that if a command executes on multiple members it
> > should always return and display all the results. Alternatively, if the
> > command succeeds then it should simply indicate success, however if it
> > fails (even partially) it should return a full list of each member and
> the
> > result of the command on each of the members.
> >
> > Thoughts; comments?
> >
> > --Jens
>
>


-- 
Cheers

Jinmei

Re: Consistent results from gfsh commands

[Michael William Dodge]

+1 for consistency!

Sarge

> On 31 Oct, 2017, at 07:59, Jens Deppe  wrote:
> 
> Hi,
> 
> I've noticed that various commands, that execute on multiple members,
> return either tabulated results (one line per member - for example
> CreateRegionCommand) or a single pass/fail line. In the latter case it’s
> possible that information would get lost. For example if a command fails on
> multiple members (but not all) then the user would not have complete
> insight into where the failure occurred.
> 
> I'd like to propose that if a command executes on multiple members it
> should always return and display all the results. Alternatively, if the
> command succeeds then it should simply indicate success, however if it
> fails (even partially) it should return a full list of each member and the
> result of the command on each of the members.
> 
> Thoughts; comments?
> 
> --Jens

Consistent results from gfsh commands

[Jens Deppe]

Hi,

I've noticed that various commands, that execute on multiple members,
return either tabulated results (one line per member - for example
CreateRegionCommand) or a single pass/fail line. In the latter case it’s
possible that information would get lost. For example if a command fails on
multiple members (but not all) then the user would not have complete
insight into where the failure occurred.

I'd like to propose that if a command executes on multiple members it
should always return and display all the results. Alternatively, if the
command succeeds then it should simply indicate success, however if it
fails (even partially) it should return a full list of each member and the
result of the command on each of the members.

Thoughts; comments?

--Jens