Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Dave Barnes]

OK - you've got the votes, Mark, thanks for your contribution.
I'm persuaded by the positive arguments and assurances of low risk.

All: let's focus on getting to RC1. I'm not comfortable with "as this
release has drug on for so long, it might be just about time to reset
expectations". Let's clean up 1.13 and get it out the door.
Thanks,
Dave


On Fri, Jun 26, 2020 at 2:54 PM Owen Nichols  wrote:

> Thank Mark and Donal for detailing the risk and criticality of this
> change.  Since 1.13 is still waiting on a couple other issues, might as
> well take the opportunity to bring this in.  My vote is +1 now.
>
> On 6/26/20, 2:32 PM, "Donal Evans"  wrote:
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
> The "no" regarding the inclusion of a REST api was specifically
> referring to the inclusion of that api's design in the RFC for the restore
> redundancy feature, not whether a REST api for it should exist at all. From
> the RFC: "It is also not within the scope of this RFC to describe any REST
> API that may be created at a future point in time."[1]<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0>
> It was always intended to create a REST api for the restore redundancy
> feature, but it was outside of the scope of my knowledge at the time the
> RFC was created to describe it fully there, so the decision was to move
> forward with the "partial" RFC rather than get bogged down in fully
> describing every facet of the feature before beginning implementation.
>
> As for the risk associated with this last stage of the restore
> redundancy feature, as far as I can tell, it's very low. The core changes
> are already in the 1.13 release branch, and have been since mid May, with
> no issues found since then. The proposed changes to be backported to the
> 1.13 release branch merely expose the REST endpoints associated with those
> changes, and don't touch core Geode at all, as far as I'm aware.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 2:09 PM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Add REST command for Restore Redundancy to
> 1.13 (GEODE-8095)
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall).  So I reject that argument that this is about "including
> the entire feature"
>
> Our "critical fixes rule" notes that our quarterly release cadence
> ensures that there is always an upcoming release vehicle for new features
> -- we will be cutting support/1.14 in just a few weeks on Aug 3.  Can you
> make the case that this feature is critical to release sooner?  As I
> understand it this feature is just an optimization -- existing code can
> already use the rebalance API to restore redundancy, it just might take a
> little longer.
>
> That said, all you need is three votes, so make your case.  Especially
> as we are already 8 weeks past the branch cut of support/1.13, and
> hopefully getting very close to an RC1, concern about risk weighs on my
> mind more than the merits.  What level of testing has this been through?
> Does it touch core code?  You may be able to get the votes just by
> demonstrating that the risk is very low.
>
> I'm a +0 for this based on the information presented so far.
>
> On 6/26/20, 11:50 AM, "Donal Evans"  wrote:
>
> +1
>
> Although normally features wouldn't really count as "critical
> fixes" that would warrant inclusion after the release branch has been cut,
> in this case, the internal API and gfsh commands for restore redundancy are
> already in the release, and it makes much more sense to include the entire
> feature in one release rather than having a semi-complete feature in 1.13
> and forcing the REST component to wait for a later release.
> 
> 

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Dave Barnes]

Looks good. Merge to 1.13 (if you haven't already).
-Dave

On Fri, Jun 26, 2020 at 10:05 AM Donal Evans  wrote:

> +1
> 
> From: Owen Nichols 
> Sent: Friday, June 26, 2020 9:59 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12
>
> +1
>
> On 6/26/20, 7:58 AM, "Ju@N"  wrote:
>
> +1
>
> On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt 
> wrote:
>
> > This small fix avoids a failure of one cluster to communicate with
> the
> > locators of another cluster, ensuring that a proper handshake for WAN
> > communications occurs.  Without the fix it’s possible that WAN
> connections
> > will not be formed and updates will not be transmitted between sites.
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Cdoevans%40vmware.com%7Cf0fdfd0e9f3f4d1225c508d819f24b53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637287875728618402sdata=ROQYORRw357JRmVBW3gCxRFoptOz%2F%2Fg6oEMoRN4vrhg%3Dreserved=0
> >
> >
>
> --
> Ju@N
>
>

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Owen Nichols]

Thank Mark and Donal for detailing the risk and criticality of this change.  
Since 1.13 is still waiting on a couple other issues, might as well take the 
opportunity to bring this in.  My vote is +1 now.

On 6/26/20, 2:32 PM, "Donal Evans"  wrote:

When restore-redundancy was first proposed, the question was asked whether 
a REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"
The "no" regarding the inclusion of a REST api was specifically referring 
to the inclusion of that api's design in the RFC for the restore redundancy 
feature, not whether a REST api for it should exist at all. From the RFC: "It 
is also not within the scope of this RFC to describe any REST API that may be 
created at a future point in 
time."[1]
 It was always intended to create a REST api for the restore redundancy 
feature, but it was outside of the scope of my knowledge at the time the RFC 
was created to describe it fully there, so the decision was to move forward 
with the "partial" RFC rather than get bogged down in fully describing every 
facet of the feature before beginning implementation.

As for the risk associated with this last stage of the restore redundancy 
feature, as far as I can tell, it's very low. The core changes are already in 
the 1.13 release branch, and have been since mid May, with no issues found 
since then. The proposed changes to be backported to the 1.13 release branch 
merely expose the REST endpoints associated with those changes, and don't touch 
core Geode at all, as far as I'm aware.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0

From: Owen Nichols 
Sent: Friday, June 26, 2020 2:09 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

When restore-redundancy was first proposed, the question was asked whether 
a REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"

Our "critical fixes rule" notes that our quarterly release cadence ensures 
that there is always an upcoming release vehicle for new features -- we will be 
cutting support/1.14 in just a few weeks on Aug 3.  Can you make the case that 
this feature is critical to release sooner?  As I understand it this feature is 
just an optimization -- existing code can already use the rebalance API to 
restore redundancy, it just might take a little longer.

That said, all you need is three votes, so make your case.  Especially as 
we are already 8 weeks past the branch cut of support/1.13, and hopefully 
getting very close to an RC1, concern about risk weighs on my mind more than 
the merits.  What level of testing has this been through?  Does it touch core 
code?  You may be able to get the votes just by demonstrating that the risk is 
very low.

I'm a +0 for this based on the information presented so far.

On 6/26/20, 11:50 AM, "Donal Evans"  wrote:

+1

Although normally features wouldn't really count as "critical fixes" 
that would warrant inclusion after the release branch has been cut, in this 
case, the internal API and gfsh commands for restore redundancy are already in 
the release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored 
to allow there to be a REST call to invoke a restore redundancy. At this point, 
looking forward to the 1.13 release it would be great if we could fit this into 
the 1.13 release.

What do people think?

   

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Donal Evans]

When restore-redundancy was first proposed, the question was asked whether a 
REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"
The "no" regarding the inclusion of a REST api was specifically referring to 
the inclusion of that api's design in the RFC for the restore redundancy 
feature, not whether a REST api for it should exist at all. From the RFC: "It 
is also not within the scope of this RFC to describe any REST API that may be 
created at a future point in 
time."[1]
 It was always intended to create a REST api for the restore redundancy 
feature, but it was outside of the scope of my knowledge at the time the RFC 
was created to describe it fully there, so the decision was to move forward 
with the "partial" RFC rather than get bogged down in fully describing every 
facet of the feature before beginning implementation.

As for the risk associated with this last stage of the restore redundancy 
feature, as far as I can tell, it's very low. The core changes are already in 
the 1.13 release branch, and have been since mid May, with no issues found 
since then. The proposed changes to be backported to the 1.13 release branch 
merely expose the REST endpoints associated with those changes, and don't touch 
core Geode at all, as far as I'm aware.

[1] 
https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands#RedundancyGfshCommands-Anti-Goals

From: Owen Nichols 
Sent: Friday, June 26, 2020 2:09 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

When restore-redundancy was first proposed, the question was asked whether a 
REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"

Our "critical fixes rule" notes that our quarterly release cadence ensures that 
there is always an upcoming release vehicle for new features -- we will be 
cutting support/1.14 in just a few weeks on Aug 3.  Can you make the case that 
this feature is critical to release sooner?  As I understand it this feature is 
just an optimization -- existing code can already use the rebalance API to 
restore redundancy, it just might take a little longer.

That said, all you need is three votes, so make your case.  Especially as we 
are already 8 weeks past the branch cut of support/1.13, and hopefully getting 
very close to an RC1, concern about risk weighs on my mind more than the 
merits.  What level of testing has this been through?  Does it touch core code? 
 You may be able to get the votes just by demonstrating that the risk is very 
low.

I'm a +0 for this based on the information presented so far.

On 6/26/20, 11:50 AM, "Donal Evans"  wrote:

+1

Although normally features wouldn't really count as "critical fixes" that 
would warrant inclusion after the release branch has been cut, in this case, 
the internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to 
allow there to be a REST call to invoke a restore redundancy. At this point, 
looking forward to the 1.13 release it would be great if we could fit this into 
the 1.13 release.

What do people think?

Thanks,
Mark

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Mark Hanson]

I can appreciate your perspective. I think there are three key things when 
looking at whether or not to add this to the 1.13 release or not.
1) this is a desirable feature that we were hoping to use internally at VMware 
and with our current release cadence, it is unclear when the next release is 
that would pick this up.
2) It was not initially expected to go in, but as this release has drug on for 
so long, it might be just about time to reset expectations for 1.13.
3) Given that that there is unit and DUnit testing in this code I think it is 
sufficiently tested to not be of significant concern in that regard. The core 
refactoring is already in 1.13 and this additional feature work is just 
enabling Restore Redundancy through REST. This work to enable that as mentioned 
has unit and DUnit tests.

Thanks,
Mark


> On Jun 26, 2020, at 2:09 PM, Owen Nichols  wrote:
> 
> When restore-redundancy was first proposed, the question was asked whether a 
> REST api would be part of that, and the answer was an emphatic "no" (largely 
> due to the continuing "experimental" labeling on the REST API, as I recall).  
> So I reject that argument that this is about "including the entire feature"
> 
> Our "critical fixes rule" notes that our quarterly release cadence ensures 
> that there is always an upcoming release vehicle for new features -- we will 
> be cutting support/1.14 in just a few weeks on Aug 3.  Can you make the case 
> that this feature is critical to release sooner?  As I understand it this 
> feature is just an optimization -- existing code can already use the 
> rebalance API to restore redundancy, it just might take a little longer.
> 
> That said, all you need is three votes, so make your case.  Especially as we 
> are already 8 weeks past the branch cut of support/1.13, and hopefully 
> getting very close to an RC1, concern about risk weighs on my mind more than 
> the merits.  What level of testing has this been through?  Does it touch core 
> code?  You may be able to get the votes just by demonstrating that the risk 
> is very low.
> 
> I'm a +0 for this based on the information presented so far.
> 
> On 6/26/20, 11:50 AM, "Donal Evans"  wrote:
> 
>+1
> 
>Although normally features wouldn't really count as "critical fixes" that 
> would warrant inclusion after the release branch has been cut, in this case, 
> the internal API and gfsh commands for restore redundancy are already in the 
> release, and it makes much more sense to include the entire feature in one 
> release rather than having a semi-complete feature in 1.13 and forcing the 
> REST component to wait for a later release.
>
>From: Mark Hanson 
>Sent: Friday, June 26, 2020 10:06 AM
>To: dev@geode.apache.org 
>Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
> (GEODE-8095)
> 
>Hello All,
> 
>The core of the restore redundancy call structure has been refactored to 
> allow there to be a REST call to invoke a restore redundancy. At this point, 
> looking forward to the 1.13 release it would be great if we could fit this 
> into the 1.13 release.
> 
>What do people think?
> 
>Thanks,
>Mark
> 

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Owen Nichols]

When restore-redundancy was first proposed, the question was asked whether a 
REST api would be part of that, and the answer was an emphatic "no" (largely 
due to the continuing "experimental" labeling on the REST API, as I recall).  
So I reject that argument that this is about "including the entire feature"

Our "critical fixes rule" notes that our quarterly release cadence ensures that 
there is always an upcoming release vehicle for new features -- we will be 
cutting support/1.14 in just a few weeks on Aug 3.  Can you make the case that 
this feature is critical to release sooner?  As I understand it this feature is 
just an optimization -- existing code can already use the rebalance API to 
restore redundancy, it just might take a little longer.

That said, all you need is three votes, so make your case.  Especially as we 
are already 8 weeks past the branch cut of support/1.13, and hopefully getting 
very close to an RC1, concern about risk weighs on my mind more than the 
merits.  What level of testing has this been through?  Does it touch core code? 
 You may be able to get the votes just by demonstrating that the risk is very 
low.

I'm a +0 for this based on the information presented so far.

On 6/26/20, 11:50 AM, "Donal Evans"  wrote:

+1

Although normally features wouldn't really count as "critical fixes" that 
would warrant inclusion after the release branch has been cut, in this case, 
the internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to 
allow there to be a REST call to invoke a restore redundancy. At this point, 
looking forward to the 1.13 release it would be great if we could fit this into 
the 1.13 release.

What do people think?

Thanks,
Mark

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Anilkumar Gingade]

+1 As Donal said, complete the feature with all the available APIs.

On 6/26/20, 11:50 AM, "Donal Evans"  wrote:

+1

Although normally features wouldn't really count as "critical fixes" that 
would warrant inclusion after the release branch has been cut, in this case, 
the internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 
(GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to 
allow there to be a REST call to invoke a restore redundancy. At this point, 
looking forward to the 1.13 release it would be great if we could fit this into 
the 1.13 release.

What do people think?

Thanks,
Mark

Re: Fate of master branch

[Dave Barnes]

+1 if we can override git’s ‘master’ default and establish ‘develop’ in its 
place. Otherwise renaming to ‘main’ would solve the problem with the negative 
connotations.

NB: Mark, I think the 3-vote convention is just for back-ports to the 
release-branch. I don’t think of it as applying to a general discussion like 
this one.

> On Jun 26, 2020, at 9:42 AM, Anthony Baker  wrote:
> 
> By just do it, I assume you mean:
> 
> - Contact delete master where not needed
> - Rename master to main when needed
> - Contact INFRA to change the default branch
> - Update README and CI jobs as needed
> 
> Across *all* geode repos.
> 
> 
> Anthony
> 
> 
>> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
>> 
>> +1 to delete. No good reason to keep it that I know of. I think I am the 
>> third +1 with no -1s so just do it.
>> 
>> Thanks,
>> Mark
>> 
>>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
>>> 
>>> +1 to deleting. Given we tag everything properly on the other branches, I
>>> don't see the need for it either.
>>> 
>>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>>  wrote:
>>> 
 +1 for deleting master branch. An also for updating the wiki page about
 branching that Alberto pointed out.
 
 De: Bruce Schuchardt 
 Enviado: viernes, 26 de junio de 2020 17:37
 Para: dev@geode.apache.org 
 Asunto: Re: Fate of master branch
 
 Let's just delete it.  I need to do that in my own repos as well.
 
 On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
 
  Apologies if this has been addressed already and I missed it.  In
 keeping with other OSS projects, I believe it’s time we did something about
 removing the insensitive term master from Geode repositories.
 
  One choice a lot of projects appear to be going with is a simple
 rename from master • main.  In our own case, however, master isn’t really
 in use for anything vital.  We track releases with a tag and a branch to
 backport fixes to, and the develop branch is the “source of truth”
 latest-and-greatest version of the code.  We could thus simply delete
 master with no loss I’m aware of.  Any opinions?
 
  Thanks,
 
  Blake
 
 
 
>> 
> 

Re: [PROPOSAL] Add windows jobs to PR checks

[Xiaojian Zhou]

What I am looking for is a script like following:

./regression -Z  deploy \
  -n  \
  -o  \
  -g  \
  -u  \
  -t  \
  -k  \
  -F  \
  

  Example:
./regression deploy -n 10 -o centos7 \
-g 
~/gemfire/closed/pivotalgf-assembly/build/distributions/pivotal-gemfire-regression-0.0.0.tgz
 \
-k ~/.ssh/id_rsa.pub -u johndoe -t storageteam myregression
```

Operating systems to choose from are:
* centos7
* rhel7
* ubuntu14*
* ubuntu16*
* sles12*
* sles11*
* windows
^ >

We use to have a
 script call "precheckin". I forgot if we can select operating system like 
above "regression" script. 

On 6/25/20, 4:09 PM, "Xiaojian Zhou"  wrote:

I vote to is also with current/existing process (not running for every PR).

We can create an on-request prechecking running on windows machine like 
what we did for running some regression tests, if someone really need to run it 
on windows (Actually, I'd love to have this tool)

On 6/25/20, 1:52 PM, "Anilkumar Gingade"  wrote:

Looking at the cost and value derived; My vote is with current/existing 
process (not running for every PR).

On 6/25/20, 11:39 AM, "Mark Hanson"  wrote:

I support adding it in, but I think the time wasted is less than 
you think. I think for me the most important thing is finding an issue when it 
is put in.

I think the current way is actually faster and more efficient, 
because every PR doesn’t have to wait the 4 hours and in reality the number is 
of windows failures is lower than the number of linux failures.

Just a thought.

Thanks,
Mark


> On Jun 25, 2020, at 11:30 AM, Jianxia Chen  
wrote:
> 
> +1 to add Windows tests to the PR pipeline. It may take longer 
time to run
> (up to 4 hours). But consider the time wasted on reverting, 
fixing and
> resubmitting, if there is a failure after merging to the develop 
branch. It
> is better to add the Windows tests to the PR pipeline. We can 
reevaluate
> and optimize the pipeline if the long running time is truly a 
concern.
> 
> On Thu, Jun 25, 2020 at 9:29 AM Kirk Lund  
wrote:
> 
>> I merged some new AcceptanceTests to develop after having my PR 
go GREEN.
>> But now these tests are failing in Windows.
>> 
>> I'd like to propose that we add the Windows jobs to our PR 
checks if we
>> plan to keep testing on Windows in CI.
>> 
>> Please vote or discuss.
>> 
>> Thanks,
>> Kirk
>> 

Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Donal Evans]

+1

Although normally features wouldn't really count as "critical fixes" that would 
warrant inclusion after the release branch has been cut, in this case, the 
internal API and gfsh commands for restore redundancy are already in the 
release, and it makes much more sense to include the entire feature in one 
release rather than having a semi-complete feature in 1.13 and forcing the REST 
component to wait for a later release.

From: Mark Hanson 
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org 
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

Hello All,

The core of the restore redundancy call structure has been refactored to allow 
there to be a REST call to invoke a restore redundancy. At this point, looking 
forward to the 1.13 release it would be great if we could fit this into the 
1.13 release.

What do people think?

Thanks,
Mark

Re: Fate of master branch

[Jacob Barrett]

> On Jun 26, 2020, at 9:40 AM, Anthony Baker  wrote:
> 
> For geode-examples, there is more impact since master is the default branch 
> and anyone who has accessed these examples would be affected.  I think it’s 
> still worth it to make the switch.

I wonder if it makes sense put current examples in geode-examples/develop and 
have them depend on what is on geode/develop. Then have branches and tags that 
mirror geode. It was always a little unclear to me what geode-examples/master 
was doing. If the two repos kept in lock step I think the confusion goes away.

-Jake

Re: Docker on Windows

[Jacob Barrett]

If the effort to do both is less than the sum of each individually then I say 
lets do it.

Kirk, I recall you putting some effort into JUnit 5 at some point. 

-Jake


> On Jun 26, 2020, at 11:13 AM, Jens Deppe  wrote:
> 
> A bigger effort (but I think more correct and sustainable) would be to switch 
> to junit 5 where something like this could more easily be implemented.
> 
> --Jens
> 
> On 6/26/20, 9:11 AM, "Robert Houghton"  wrote:
> 
>The plugin code that spawns junit test workers on containers needs some 
> serious help. Aside from the benefit we would get on windows, we also are 
> blocked on getting to the next major version of Gradle with the current tool. 
> I really think it might be easier to write our own Gradle plugin at this 
> point.
> 
> 
>From: Jacob Barrett 
>Date: Thursday, June 25, 2020 at 12:26 PM
>To: dev@geode.apache.org 
>Subject: Docker on Windows
> 
>> On Jun 25, 2020, at 12:23 PM, Jens Deppe  wrote:
>> It's been a couple of years since Sai and I tried (but failed) to dockerize 
>> the tests. I'm sure docker support has improved and it might be worth trying 
>> that again.
> 
>Docker on windows has improved a lot but wasn’t the major issue the docker 
> plugin for Gradle needed some serious work?
> 
>I have recently been experimenting with the Docker/Kubernetes for Windows 
> experience. Perhaps we can take another stab at this issue.
> 
>-Jake
> 

Re: Docker on Windows

[Jens Deppe]

A bigger effort (but I think more correct and sustainable) would be to switch 
to junit 5 where something like this could more easily be implemented.

--Jens

On 6/26/20, 9:11 AM, "Robert Houghton"  wrote:

The plugin code that spawns junit test workers on containers needs some 
serious help. Aside from the benefit we would get on windows, we also are 
blocked on getting to the next major version of Gradle with the current tool. I 
really think it might be easier to write our own Gradle plugin at this point.


From: Jacob Barrett 
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org 
Subject: Docker on Windows

> On Jun 25, 2020, at 12:23 PM, Jens Deppe  wrote:
> It's been a couple of years since Sai and I tried (but failed) to 
dockerize the tests. I'm sure docker support has improved and it might be worth 
trying that again.

Docker on windows has improved a lot but wasn’t the major issue the docker 
plugin for Gradle needed some serious work?

I have recently been experimenting with the Docker/Kubernetes for Windows 
experience. Perhaps we can take another stab at this issue.

-Jake

[Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)

[Mark Hanson]

Hello All,

The core of the restore redundancy call structure has been refactored to allow 
there to be a REST call to invoke a restore redundancy. At this point, looking 
forward to the 1.13 release it would be great if we could fit this into the 
1.13 release.

What do people think?

Thanks,
Mark

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Donal Evans]

+1

From: Owen Nichols 
Sent: Friday, June 26, 2020 9:59 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

+1

On 6/26/20, 7:58 AM, "Ju@N"  wrote:

+1

On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt  wrote:

> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs.  Without the fix it’s possible that WAN connections
> will not be formed and updates will not be transmitted between sites.
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Cdoevans%40vmware.com%7Cf0fdfd0e9f3f4d1225c508d819f24b53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637287875728618402sdata=ROQYORRw357JRmVBW3gCxRFoptOz%2F%2Fg6oEMoRN4vrhg%3Dreserved=0
>
>

--
Ju@N

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Owen Nichols]

+1

On 6/26/20, 7:58 AM, "Ju@N"  wrote:

+1

On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt  wrote:

> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs.  Without the fix it’s possible that WAN connections
> will not be formed and updates will not be transmitted between sites.
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5306data=02%7C01%7Conichols%40vmware.com%7C2a43a44fbd4448a743d908d819e16e70%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637287803298327568sdata=4JKZn1TbHvqTuQWDF1sh3POHys7IdgTujNQdZHVI%2FCs%3Dreserved=0
>
>

-- 
Ju@N

Re: Fate of master branch

[Anthony Baker]

By just do it, I assume you mean:

- Contact delete master where not needed
- Rename master to main when needed
- Contact INFRA to change the default branch
- Update README and CI jobs as needed

Across *all* geode repos.


Anthony


> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
> 
> +1 to delete. No good reason to keep it that I know of. I think I am the 
> third +1 with no -1s so just do it.
> 
> Thanks,
> Mark
> 
>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
>> 
>> +1 to deleting. Given we tag everything properly on the other branches, I
>> don't see the need for it either.
>> 
>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>  wrote:
>> 
>>> +1 for deleting master branch. An also for updating the wiki page about
>>> branching that Alberto pointed out.
>>> 
>>> De: Bruce Schuchardt 
>>> Enviado: viernes, 26 de junio de 2020 17:37
>>> Para: dev@geode.apache.org 
>>> Asunto: Re: Fate of master branch
>>> 
>>> Let's just delete it.  I need to do that in my own repos as well.
>>> 
>>> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>>> 
>>>   Apologies if this has been addressed already and I missed it.  In
>>> keeping with other OSS projects, I believe it’s time we did something about
>>> removing the insensitive term master from Geode repositories.
>>> 
>>>   One choice a lot of projects appear to be going with is a simple
>>> rename from master • main.  In our own case, however, master isn’t really
>>> in use for anything vital.  We track releases with a tag and a branch to
>>> backport fixes to, and the develop branch is the “source of truth”
>>> latest-and-greatest version of the code.  We could thus simply delete
>>> master with no loss I’m aware of.  Any opinions?
>>> 
>>>   Thanks,
>>> 
>>>   Blake
>>> 
>>> 
>>> 
> 

Re: Fate of master branch

[Anthony Baker]

Let’s check all the repos:

geode
master is the latest released code
work is done on develop (default branch)

geode-benchmarks
master is the latest released code
work is done on develop (default branch)

geode-dotnet-core-client
master is the latest released code
work is done on develop (default branch)

geode-native
master is the latest released code
work is done on develop (default branch)

geode-site
asf-site is the CMS branch for publishing
work is done on master (default branch)

geode-examples
master is the default branch and latest release
work is done on develop

geode-kafka-connector
work is done on master (default branch)


For some repos, removing `master` entirely seems pretty low impact.  

Side note:  when I work in other projects it’s always nice to `git clone XXX` 
and be working on a known good branch.  For the geode repo the default branch 
is develop so that doesn’t really apply—it’s just as much friction to checkout 
main as rel/v1.12.0.  

For geode-examples, there is more impact since master is the default branch and 
anyone who has accessed these examples would be affected.  I think it’s still 
worth it to make the switch.

Are there any effects on CI jobs?  README files?


Side node #2:  GitHub has suggested they will be supporting this name change, 
but the details of when and how are unclear.  And other Apache projects are 
moving in this direction as well.

Anthony


> On Jun 26, 2020, at 8:37 AM, Bruce Schuchardt  wrote:
> 
> Let's just delete it.  I need to do that in my own repos as well.
> 
> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
> 
>Apologies if this has been addressed already and I missed it.  In keeping 
> with other OSS projects, I believe it’s time we did something about removing 
> the insensitive term master from Geode repositories.
> 
>One choice a lot of projects appear to be going with is a simple rename 
> from master • main.  In our own case, however, master isn’t really in use for 
> anything vital.  We track releases with a tag and a branch to backport fixes 
> to, and the develop branch is the “source of truth” latest-and-greatest 
> version of the code.  We could thus simply delete master with no loss I’m 
> aware of.  Any opinions?
> 
>Thanks,
> 
>Blake
> 
> 

Re: Fate of master branch

[Mark Hanson]

+1 to delete. No good reason to keep it that I know of. I think I am the third 
+1 with no -1s so just do it.

Thanks,
Mark

> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
> 
> +1 to deleting. Given we tag everything properly on the other branches, I
> don't see the need for it either.
> 
> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>  wrote:
> 
>> +1 for deleting master branch. An also for updating the wiki page about
>> branching that Alberto pointed out.
>> 
>> De: Bruce Schuchardt 
>> Enviado: viernes, 26 de junio de 2020 17:37
>> Para: dev@geode.apache.org 
>> Asunto: Re: Fate of master branch
>> 
>> Let's just delete it.  I need to do that in my own repos as well.
>> 
>> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>> 
>>Apologies if this has been addressed already and I missed it.  In
>> keeping with other OSS projects, I believe it’s time we did something about
>> removing the insensitive term master from Geode repositories.
>> 
>>One choice a lot of projects appear to be going with is a simple
>> rename from master • main.  In our own case, however, master isn’t really
>> in use for anything vital.  We track releases with a tag and a branch to
>> backport fixes to, and the develop branch is the “source of truth”
>> latest-and-greatest version of the code.  We could thus simply delete
>> master with no loss I’m aware of.  Any opinions?
>> 
>>Thanks,
>> 
>>Blake
>> 
>> 
>> 

Re: Fate of master branch

[Alexander Murmann]

+1 to deleting. Given we tag everything properly on the other branches, I
don't see the need for it either.

On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
 wrote:

> +1 for deleting master branch. An also for updating the wiki page about
> branching that Alberto pointed out.
> 
> De: Bruce Schuchardt 
> Enviado: viernes, 26 de junio de 2020 17:37
> Para: dev@geode.apache.org 
> Asunto: Re: Fate of master branch
>
> Let's just delete it.  I need to do that in my own repos as well.
>
> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>
> Apologies if this has been addressed already and I missed it.  In
> keeping with other OSS projects, I believe it’s time we did something about
> removing the insensitive term master from Geode repositories.
>
> One choice a lot of projects appear to be going with is a simple
> rename from master • main.  In our own case, however, master isn’t really
> in use for anything vital.  We track releases with a tag and a branch to
> backport fixes to, and the develop branch is the “source of truth”
> latest-and-greatest version of the code.  We could thus simply delete
> master with no loss I’m aware of.  Any opinions?
>
> Thanks,
>
> Blake
>
>
>

Re: Successful build on windows

[Kirk Lund]

My guess is that there is a background thread that throws a CancelException
which is caught and logged AFTER the DistributedSystem disconnect. Any
logging after that goes to stdout logging instead of the server/locator log
file.

Otherwise, it might be a System.out or throwable.printStackTrace call
somewhere in the code.

On Thu, Jun 25, 2020 at 11:35 PM Alberto Gomez 
wrote:

> Hi Kirk,
>
> I build on Ubuntu 18.02 and I occasionally see the partial stack traces
> you mentioned on geode-wan:tests you mentioned. So it is not just a Windows
> thing.
>
> Never figured out what they provoked them and neither how to get them
> consistently.
>
> BR,
>
> Alberto
>
> 
> From: Kirk Lund 
> Sent: Thursday, June 25, 2020 11:53 PM
> To: dev@geode.apache.org 
> Subject: Successful build on windows
>
> In case anyone is interested in the developer experience building with unit
> tests on windows:
>
> It succeeds (after a couple tries) but something in geode-wan:test spits
> out a partial stack trace. Since all the tests passed, I don't really see a
> way to find out which test generated it.
>
> C:\Users\kirkl\dev\geode>gradlew.bat build
>
>
>
> *> Task :geode-wan:testat
>
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1780)
>   at
>
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1879)*
>
> > Task :combineReports
> All test reports at C:\Users\kirkl\dev\geode\build/reports/combined
>
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 6.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See
>
> https://docs.gradle.org/5.4/userguide/command_line_interface.html#sec:command_line_warnings
>
> BUILD SUCCESSFUL in 3m 52s
> 532 actionable tasks: 97 executed, 435 up-to-date
>

Re: Docker on Windows

[Robert Houghton]

The plugin code that spawns junit test workers on containers needs some serious 
help. Aside from the benefit we would get on windows, we also are blocked on 
getting to the next major version of Gradle with the current tool. I really 
think it might be easier to write our own Gradle plugin at this point.


From: Jacob Barrett 
Date: Thursday, June 25, 2020 at 12:26 PM
To: dev@geode.apache.org 
Subject: Docker on Windows

> On Jun 25, 2020, at 12:23 PM, Jens Deppe  wrote:
> It's been a couple of years since Sai and I tried (but failed) to dockerize 
> the tests. I'm sure docker support has improved and it might be worth trying 
> that again.

Docker on windows has improved a lot but wasn’t the major issue the docker 
plugin for Gradle needed some serious work?

I have recently been experimenting with the Docker/Kubernetes for Windows 
experience. Perhaps we can take another stab at this issue.

-Jake

RE: Fate of master branch

[Alberto Bustamante Reyes]

+1 for deleting master branch. An also for updating the wiki page about 
branching that Alberto pointed out.

De: Bruce Schuchardt 
Enviado: viernes, 26 de junio de 2020 17:37
Para: dev@geode.apache.org 
Asunto: Re: Fate of master branch

Let's just delete it.  I need to do that in my own repos as well.

On 6/26/20, 8:05 AM, "Blake Bender"  wrote:

Apologies if this has been addressed already and I missed it.  In keeping 
with other OSS projects, I believe it’s time we did something about removing 
the insensitive term master from Geode repositories.

One choice a lot of projects appear to be going with is a simple rename 
from master • main.  In our own case, however, master isn’t really in use for 
anything vital.  We track releases with a tag and a branch to backport fixes 
to, and the develop branch is the “source of truth” latest-and-greatest version 
of the code.  We could thus simply delete master with no loss I’m aware of.  
Any opinions?

Thanks,

Blake

Re: Fate of master branch

[Bruce Schuchardt]

Let's just delete it.  I need to do that in my own repos as well.

On 6/26/20, 8:05 AM, "Blake Bender"  wrote:

Apologies if this has been addressed already and I missed it.  In keeping 
with other OSS projects, I believe it’s time we did something about removing 
the insensitive term master from Geode repositories.

One choice a lot of projects appear to be going with is a simple rename 
from master • main.  In our own case, however, master isn’t really in use for 
anything vital.  We track releases with a tag and a branch to backport fixes 
to, and the develop branch is the “source of truth” latest-and-greatest version 
of the code.  We could thus simply delete master with no loss I’m aware of.  
Any opinions?

Thanks,

Blake

Re: Fate of master branch

[Alberto Gomez]

I agree also on removing the master branch.

As a relatively new member of the community it's been a source of confusion to 
me when looking at what is said in the wiki about it 
(https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching) 
and comparing it with the actual practice.

Alberto G.

From: Jacob Barrett 
Sent: Friday, June 26, 2020 5:26 PM
To: dev@geode.apache.org 
Subject: Re: Fate of master branch

I am 100% in favor or dropping the master branch completely. I felt like it was 
always a source of confusion. Was it the most recent release or the latest 
version number. I know we have had issues with even correctly merging the 
latest version back into it sometimes.

I really can’t see any reason for keeping it around.

-Jake



> On Jun 26, 2020, at 8:05 AM, Blake Bender  wrote:
>
> Apologies if this has been addressed already and I missed it.  In keeping 
> with other OSS projects, I believe it’s time we did something about removing 
> the insensitive term master from Geode repositories.
>
> One choice a lot of projects appear to be going with is a simple rename from 
> master • main.  In our own case, however, master isn’t really in use for 
> anything vital.  We track releases with a tag and a branch to backport fixes 
> to, and the develop branch is the “source of truth” latest-and-greatest 
> version of the code.  We could thus simply delete master with no loss I’m 
> aware of.  Any opinions?
>
> Thanks,
>
> Blake
>

Re: Fate of master branch

[Jacob Barrett]

I am 100% in favor or dropping the master branch completely. I felt like it was 
always a source of confusion. Was it the most recent release or the latest 
version number. I know we have had issues with even correctly merging the 
latest version back into it sometimes. 

I really can’t see any reason for keeping it around. 

-Jake



> On Jun 26, 2020, at 8:05 AM, Blake Bender  wrote:
> 
> Apologies if this has been addressed already and I missed it.  In keeping 
> with other OSS projects, I believe it’s time we did something about removing 
> the insensitive term master from Geode repositories.
> 
> One choice a lot of projects appear to be going with is a simple rename from 
> master • main.  In our own case, however, master isn’t really in use for 
> anything vital.  We track releases with a tag and a branch to backport fixes 
> to, and the develop branch is the “source of truth” latest-and-greatest 
> version of the code.  We could thus simply delete master with no loss I’m 
> aware of.  Any opinions?
> 
> Thanks,
> 
> Blake
> 

Fate of master branch

[Blake Bender]

Apologies if this has been addressed already and I missed it.  In keeping with 
other OSS projects, I believe it’s time we did something about removing the 
insensitive term master from Geode repositories.

One choice a lot of projects appear to be going with is a simple rename from 
master • main.  In our own case, however, master isn’t really in use for 
anything vital.  We track releases with a tag and a branch to backport fixes 
to, and the develop branch is the “source of truth” latest-and-greatest version 
of the code.  We could thus simply delete master with no loss I’m aware of.  
Any opinions?

Thanks,

Blake

Re: [PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Ju@N]

+1

On Fri, 26 Jun 2020 at 15:51, Bruce Schuchardt  wrote:

> This small fix avoids a failure of one cluster to communicate with the
> locators of another cluster, ensuring that a proper handshake for WAN
> communications occurs.  Without the fix it’s possible that WAN connections
> will not be formed and updates will not be transmitted between sites.
>
> https://github.com/apache/geode/pull/5306
>
>

-- 
Ju@N

[PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

[Bruce Schuchardt]

This small fix avoids a failure of one cluster to communicate with the locators 
of another cluster, ensuring that a proper handshake for WAN communications 
occurs.  Without the fix it’s possible that WAN connections will not be formed 
and updates will not be transmitted between sites.

https://github.com/apache/geode/pull/5306

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Blake Bender]

Sorry for a long delay, just catching up on a ton of dev mail this morning.  
FWIW, I agree that leaving feature/WIP branches in the main repository is bad 
practice.  The ease and flexibility of branching in Git leads to a strong 
tendency towards proliferation of these things, and we really ought to apply 
some discipline to the process to keep the repo history clean.

The detailed instructions on our Wiki re explicit re: use of forks for 
contributions.  All I see in the top-level "Contributing" page, however, is 
this:

>>> Use a pull request to submit a code patch to the github mirror. Any new 
>>> changes should be targeted at the "develop" branch.

Perhaps we should at least add a brief note here about forking?

Thanks,

Blake




On 6/11/20, 11:25 PM, "Jacob Barrett"  wrote:



> On Jun 11, 2020, at 8:41 PM, Owen Nichols  wrote:
> 
> -1 for “banning”

:facepalm: Sorry, poor choice of words. How about “strongly discouraged” 
because of the harm enumerated perviously. 

> 
> The Geode community has strong precedent for protecting developers’ 
freedom to choose what works best for them.

Not to the detriment of others in the community.

> Maybe check if your graphical git tool-of-choice allows a branch filter 
regex, or consider git clone --single-branch?

Whether someone filters or not the issues enumerated exist even if hidden 
away.

-Jake

Re: Successful build on windows

[Alberto Gomez]

Hi Kirk,

I build on Ubuntu 18.02 and I occasionally see the partial stack traces you 
mentioned on geode-wan:tests you mentioned. So it is not just a Windows thing.

Never figured out what they provoked them and neither how to get them 
consistently.

BR,

Alberto


From: Kirk Lund 
Sent: Thursday, June 25, 2020 11:53 PM
To: dev@geode.apache.org 
Subject: Successful build on windows

In case anyone is interested in the developer experience building with unit
tests on windows:

It succeeds (after a couple tries) but something in geode-wan:test spits
out a partial stack trace. Since all the tests passed, I don't really see a
way to find out which test generated it.

C:\Users\kirkl\dev\geode>gradlew.bat build



*> Task :geode-wan:testat
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1780)
  at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1879)*

> Task :combineReports
All test reports at C:\Users\kirkl\dev\geode\build/reports/combined

Deprecated Gradle features were used in this build, making it incompatible
with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See
https://docs.gradle.org/5.4/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 3m 52s
532 actionable tasks: 97 executed, 435 up-to-date