Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/129

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/199

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/185

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/128

Broken: apache/geode#6054 (develop - ad5a311)

[Travis CI]

Build Update for apache/geode
-

Build: #6054
Status: Broken

Duration: 14 minutes and 51 seconds
Commit: ad5a311 (develop)
Author: Sean Goller
Message: [GEODE-4630] Add timestamps directories to subdivide test artifacts. 
(#1412)

View the changeset: 
https://github.com/apache/geode/compare/31b7f1581ece...ad5a311391db

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/338786566?utm_source=email&utm_medium=notification

--

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

Broken: apache/geode#6046 (develop - f69130e)

[Travis CI]

Build Update for apache/geode
-

Build: #6046
Status: Broken

Duration: 22 minutes and 5 seconds
Commit: f69130e (develop)
Author: Dave Barnes
Message: GEODE-4609: Create region gfsh command option --skip-if-exists 
defaults to false

View the changeset: 
https://github.com/apache/geode/compare/c248b1e6afb8...f69130e17e9e

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/338734841?utm_source=email&utm_medium=notification

--

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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #821 was successful.
---
Scheduled
2326 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Next release: 1.5.0

[Anthony Baker]

Hi all,

Nice work on getting the 1.4.0 release out the door!  Next up is 1.5.0.  Any 
one want to volunteer for release manager?  If you haven’t done this before and 
would like to try, please review [1].

I’ve been advocating for more frequent releases.  I’d love see a March 
release—which means we would need to be ready to cut the release branch in 
early March.

Thoughts?

Anthony

[1] 
https://cwiki.apache.org/confluence/display/GEODE/Release+Steps?src=contextnavpagetreemode
 

Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/196

Broken: apache/geode#6018 (develop - f0d40e3)

[Travis CI]

Build Update for apache/geode
-

Build: #6018
Status: Broken

Duration: 18 minutes and 13 seconds
Commit: f0d40e3 (develop)
Author: jinmeiliao
Message: GEODE-4604: rest api function execution needs to check the required p… 
(#1388)

View the changeset: 
https://github.com/apache/geode/compare/2ebd5b027afa...f0d40e34ce28

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/338540557?utm_source=email&utm_medium=notification

--

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

Re: [PROPOSAL]: deprecating create region using --template-region option

[John Blum]

Exactly, a logging/auditing *CacheListener* would possibly be useful across
multiple Regions, for instance.

Again, I don't know that this feature is as useful in tooling when an
application largely drives that based on UCs/workflows and data access
patterns.  I.e. there are many ways to skin a cat that are not necessarily
database specific, nor should they be in all cases.

On Wed, Feb 7, 2018 at 11:22 AM, Jinmei Liao  wrote:

> John,  I should have been more specific in my original proposal. It should
> read as "deprecating create region using --template-region" option in gfsh.
> I am sure the concept can be useful in other creation mechanism as long as
> they have a way to ensure that those callback are available on the member
> where they are trying to create the region.
>
> On Wed, Feb 7, 2018 at 10:56 AM, John Blum  wrote:
>
>> +0
>>
>> As an FYI, *Spring Data Geode/GemFire* already provides such a
>> capability [1], which makes much more sense from an application standpoint
>> than a tooling standpoint.
>>
>> Having said that, I would also add that this capability is 1 of the more
>> popular features in SDG (particularly from customers).  Just because it
>> does not make sense in all cases and for all manner of configurations does
>> not mean it is not incredibly useful.  Of course, SDG also supports
>> "hierarchical" configuration, or "inheritance" in the configuration with
>> the ability to compose templates as well so that things like
>> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
>> are needed, or most directly apply.
>>
>> -j
>>
>>
>> [1] https://docs.spring.io/spring-data/geode/docs/current/
>> reference/html/#bootstrap:region:templates
>>
>>
>> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe  wrote:
>>
>>> +1 for deprecating
>>> Looks to me that there are too many variations on what attributes to
>>> apply to the new region to ever get it right for all situations. As Anil
>>> said, copy and paste the command used to create the original region and
>>> modify attributes as necessary for the new region.
>>>
>>> > On Feb 7, 2018, at 10:45 AM, Nick Reich  wrote:
>>> >
>>> > +1 for deprecating --template-region. It feels like a convenience
>>> method that by it very nature has an unobvious result and would require
>>> more effort to understand so it could be used correctly by a user than the
>>> value that it presents.
>>> >
>>> > On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade <
>>> aging...@pivotal.io > wrote:
>>> > +1 for deprecating --template-region
>>> >
>>> > User can always find the command used to create the region and re-use
>>> it
>>> > (or if its in script, cut and paste the line).
>>> >
>>> > -Anil.
>>> >
>>> >
>>> > On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao >> > wrote:
>>> >
>>> > > Hi, All,
>>> > >
>>> > > currently, there are two ways to create a region, either to use a
>>> "--type"
>>> > > option indicating a region shortcut or a "--template-region" option
>>> > > specifying another regionPath where you want to copy the attribute
>>> from.
>>> > >
>>> > > First of all, we are not sure what set of attributes that make sense
>>> to
>>> > > copy to the new region. e.g listeners/loaders/writers, normally
>>> these are
>>> > > connected to a downstream database that user may/may not want the new
>>> > > region to read/write the same table. And the current implementation
>>> would
>>> > > fail to create a region from a template that has these custom
>>> callbacks
>>> > > (including listeners, loader, writer, compressor, resolvers etc). So
>>> we
>>> > > would like to understand how useful this command option is and if we
>>> can
>>> > > stop supporting it?
>>> > >
>>> > > Suggestions/feedback welcome!
>>> > >
>>> > > --
>>> > > Cheers
>>> > >
>>> > > Jinmei
>>> > >
>>> >
>>>
>>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
>
> --
> Cheers
>
> Jinmei
>



-- 
-John
john.blum10101 (skype)

Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/127

Geode unit tests completed in 'develop/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/182

Re: [PROPOSAL]: deprecating create region using --template-region option

[Jinmei Liao]

John,  I should have been more specific in my original proposal. It should
read as "deprecating create region using --template-region" option in gfsh.
I am sure the concept can be useful in other creation mechanism as long as
they have a way to ensure that those callback are available on the member
where they are trying to create the region.

On Wed, Feb 7, 2018 at 10:56 AM, John Blum  wrote:

> +0
>
> As an FYI, *Spring Data Geode/GemFire* already provides such a capability
> [1], which makes much more sense from an application standpoint than a
> tooling standpoint.
>
> Having said that, I would also add that this capability is 1 of the more
> popular features in SDG (particularly from customers).  Just because it
> does not make sense in all cases and for all manner of configurations does
> not mean it is not incredibly useful.  Of course, SDG also supports
> "hierarchical" configuration, or "inheritance" in the configuration with
> the ability to compose templates as well so that things like
> *CacheListeners/Loaders/Writers/etc* are easily localized to where they
> are needed, or most directly apply.
>
> -j
>
>
> [1] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap:region:templates
>
>
> On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe  wrote:
>
>> +1 for deprecating
>> Looks to me that there are too many variations on what attributes to
>> apply to the new region to ever get it right for all situations. As Anil
>> said, copy and paste the command used to create the original region and
>> modify attributes as necessary for the new region.
>>
>> > On Feb 7, 2018, at 10:45 AM, Nick Reich  wrote:
>> >
>> > +1 for deprecating --template-region. It feels like a convenience
>> method that by it very nature has an unobvious result and would require
>> more effort to understand so it could be used correctly by a user than the
>> value that it presents.
>> >
>> > On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade > > wrote:
>> > +1 for deprecating --template-region
>> >
>> > User can always find the command used to create the region and re-use it
>> > (or if its in script, cut and paste the line).
>> >
>> > -Anil.
>> >
>> >
>> > On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao > jil...@pivotal.io>> wrote:
>> >
>> > > Hi, All,
>> > >
>> > > currently, there are two ways to create a region, either to use a
>> "--type"
>> > > option indicating a region shortcut or a "--template-region" option
>> > > specifying another regionPath where you want to copy the attribute
>> from.
>> > >
>> > > First of all, we are not sure what set of attributes that make sense
>> to
>> > > copy to the new region. e.g listeners/loaders/writers, normally these
>> are
>> > > connected to a downstream database that user may/may not want the new
>> > > region to read/write the same table. And the current implementation
>> would
>> > > fail to create a region from a template that has these custom
>> callbacks
>> > > (including listeners, loader, writer, compressor, resolvers etc). So
>> we
>> > > would like to understand how useful this command option is and if we
>> can
>> > > stop supporting it?
>> > >
>> > > Suggestions/feedback welcome!
>> > >
>> > > --
>> > > Cheers
>> > >
>> > > Jinmei
>> > >
>> >
>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
>



-- 
Cheers

Jinmei

Re: [PROPOSAL]: deprecating create region using --template-region option

[John Blum]

+0

As an FYI, *Spring Data Geode/GemFire* already provides such a capability
[1], which makes much more sense from an application standpoint than a
tooling standpoint.

Having said that, I would also add that this capability is 1 of the more
popular features in SDG (particularly from customers).  Just because it
does not make sense in all cases and for all manner of configurations does
not mean it is not incredibly useful.  Of course, SDG also supports
"hierarchical" configuration, or "inheritance" in the configuration with
the ability to compose templates as well so that things like
*CacheListeners/Loaders/Writers/etc* are easily localized to where they are
needed, or most directly apply.

-j


[1]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap:region:templates


On Wed, Feb 7, 2018 at 10:51 AM, Kenneth Howe  wrote:

> +1 for deprecating
> Looks to me that there are too many variations on what attributes to apply
> to the new region to ever get it right for all situations. As Anil said,
> copy and paste the command used to create the original region and modify
> attributes as necessary for the new region.
>
> > On Feb 7, 2018, at 10:45 AM, Nick Reich  wrote:
> >
> > +1 for deprecating --template-region. It feels like a convenience method
> that by it very nature has an unobvious result and would require more
> effort to understand so it could be used correctly by a user than the value
> that it presents.
> >
> > On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade  > wrote:
> > +1 for deprecating --template-region
> >
> > User can always find the command used to create the region and re-use it
> > (or if its in script, cut and paste the line).
> >
> > -Anil.
> >
> >
> > On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao  jil...@pivotal.io>> wrote:
> >
> > > Hi, All,
> > >
> > > currently, there are two ways to create a region, either to use a
> "--type"
> > > option indicating a region shortcut or a "--template-region" option
> > > specifying another regionPath where you want to copy the attribute
> from.
> > >
> > > First of all, we are not sure what set of attributes that make sense to
> > > copy to the new region. e.g listeners/loaders/writers, normally these
> are
> > > connected to a downstream database that user may/may not want the new
> > > region to read/write the same table. And the current implementation
> would
> > > fail to create a region from a template that has these custom callbacks
> > > (including listeners, loader, writer, compressor, resolvers etc). So we
> > > would like to understand how useful this command option is and if we
> can
> > > stop supporting it?
> > >
> > > Suggestions/feedback welcome!
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>


-- 
-John
john.blum10101 (skype)

Re: [PROPOSAL]: deprecating create region using --template-region option

[Kenneth Howe]

+1 for deprecating
Looks to me that there are too many variations on what attributes to apply to 
the new region to ever get it right for all situations. As Anil said, copy and 
paste the command used to create the original region and modify attributes as 
necessary for the new region.

> On Feb 7, 2018, at 10:45 AM, Nick Reich  wrote:
> 
> +1 for deprecating --template-region. It feels like a convenience method that 
> by it very nature has an unobvious result and would require more effort to 
> understand so it could be used correctly by a user than the value that it 
> presents.
> 
> On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade  > wrote:
> +1 for deprecating --template-region
> 
> User can always find the command used to create the region and re-use it
> (or if its in script, cut and paste the line).
> 
> -Anil.
> 
> 
> On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao  > wrote:
> 
> > Hi, All,
> >
> > currently, there are two ways to create a region, either to use a "--type"
> > option indicating a region shortcut or a "--template-region" option
> > specifying another regionPath where you want to copy the attribute from.
> >
> > First of all, we are not sure what set of attributes that make sense to
> > copy to the new region. e.g listeners/loaders/writers, normally these are
> > connected to a downstream database that user may/may not want the new
> > region to read/write the same table. And the current implementation would
> > fail to create a region from a template that has these custom callbacks
> > (including listeners, loader, writer, compressor, resolvers etc). So we
> > would like to understand how useful this command option is and if we can
> > stop supporting it?
> >
> > Suggestions/feedback welcome!
> >
> > --
> > Cheers
> >
> > Jinmei
> >
> 

Re: [PROPOSAL]: deprecating create region using --template-region option

[Nick Reich]

+1 for deprecating --template-region. It feels like a convenience method
that by it very nature has an unobvious result and would require more
effort to understand so it could be used correctly by a user than the value
that it presents.

On Wed, Feb 7, 2018 at 10:26 AM, Anilkumar Gingade 
wrote:

> +1 for deprecating --template-region
>
> User can always find the command used to create the region and re-use it
> (or if its in script, cut and paste the line).
>
> -Anil.
>
>
> On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao  wrote:
>
> > Hi, All,
> >
> > currently, there are two ways to create a region, either to use a
> "--type"
> > option indicating a region shortcut or a "--template-region" option
> > specifying another regionPath where you want to copy the attribute from.
> >
> > First of all, we are not sure what set of attributes that make sense to
> > copy to the new region. e.g listeners/loaders/writers, normally these are
> > connected to a downstream database that user may/may not want the new
> > region to read/write the same table. And the current implementation would
> > fail to create a region from a template that has these custom callbacks
> > (including listeners, loader, writer, compressor, resolvers etc). So we
> > would like to understand how useful this command option is and if we can
> > stop supporting it?
> >
> > Suggestions/feedback welcome!
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [PROPOSAL]: deprecating create region using --template-region option

[Anilkumar Gingade]

+1 for deprecating --template-region

User can always find the command used to create the region and re-use it
(or if its in script, cut and paste the line).

-Anil.


On Wed, Feb 7, 2018 at 9:49 AM, Jinmei Liao  wrote:

> Hi, All,
>
> currently, there are two ways to create a region, either to use a "--type"
> option indicating a region shortcut or a "--template-region" option
> specifying another regionPath where you want to copy the attribute from.
>
> First of all, we are not sure what set of attributes that make sense to
> copy to the new region. e.g listeners/loaders/writers, normally these are
> connected to a downstream database that user may/may not want the new
> region to read/write the same table. And the current implementation would
> fail to create a region from a template that has these custom callbacks
> (including listeners, loader, writer, compressor, resolvers etc). So we
> would like to understand how useful this command option is and if we can
> stop supporting it?
>
> Suggestions/feedback welcome!
>
> --
> Cheers
>
> Jinmei
>

[PROPOSAL]: deprecating create region using --template-region option

[Jinmei Liao]

Hi, All,

currently, there are two ways to create a region, either to use a "--type"
option indicating a region shortcut or a "--template-region" option
specifying another regionPath where you want to copy the attribute from.

First of all, we are not sure what set of attributes that make sense to
copy to the new region. e.g listeners/loaders/writers, normally these are
connected to a downstream database that user may/may not want the new
region to read/write the same table. And the current implementation would
fail to create a region from a template that has these custom callbacks
(including listeners, loader, writer, compressor, resolvers etc). So we
would like to understand how useful this command option is and if we can
stop supporting it?

Suggestions/feedback welcome!

-- 
Cheers

Jinmei