[DISCUSS] - Move gfsh into its own submodule

[Jens Deppe]

Hello All,

We'd like to propose moving gfsh and all associated commands into its own
gradle submodule (implicitly thus also producing a separate maven
artifact). The underlying intent is to decouple geode core from any Spring
dependencies.

The proposal is outlined here:
https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project

Please provide feedback for this proposal *on this email thread* and not in
the comment section of the proposal page.

The deadline for this proposal will be Monday, December 2.

Thanks in advance for feedback / comments.

--Jens & Patrick

Re: [DISCUSS] - Move gfsh into its own submodule

[Jinmei Liao]

+100. Would be a great move.

On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe  wrote:

> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode core from any Spring
> dependencies.
>
> The proposal is outlined here:
>
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
>
> Please provide feedback for this proposal *on this email thread* and not in
> the comment section of the proposal page.
>
> The deadline for this proposal will be Monday, December 2.
>
> Thanks in advance for feedback / comments.
>
> --Jens & Patrick
>


-- 
Cheers

Jinmei

Re: [DISCUSS] - Move gfsh into its own submodule

[Donal Evans]

+1

Especially with the new management functionality on the way, this seems
like a good idea.

On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao  wrote:

> +100. Would be a great move.
>
> On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe  wrote:
>
> > Hello All,
> >
> > We'd like to propose moving gfsh and all associated commands into its own
> > gradle submodule (implicitly thus also producing a separate maven
> > artifact). The underlying intent is to decouple geode core from any
> Spring
> > dependencies.
> >
> > The proposal is outlined here:
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> >
> > Please provide feedback for this proposal *on this email thread* and not
> in
> > the comment section of the proposal page.
> >
> > The deadline for this proposal will be Monday, December 2.
> >
> > Thanks in advance for feedback / comments.
> >
> > --Jens & Patrick
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Kirk Lund]

+1 yes!

On Fri, Nov 22, 2019 at 9:15 AM Donal Evans  wrote:

> +1
>
> Especially with the new management functionality on the way, this seems
> like a good idea.
>
> On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao  wrote:
>
> > +100. Would be a great move.
> >
> > On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe  wrote:
> >
> > > Hello All,
> > >
> > > We'd like to propose moving gfsh and all associated commands into its
> own
> > > gradle submodule (implicitly thus also producing a separate maven
> > > artifact). The underlying intent is to decouple geode core from any
> > Spring
> > > dependencies.
> > >
> > > The proposal is outlined here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > >
> > > Please provide feedback for this proposal *on this email thread* and
> not
> > in
> > > the comment section of the proposal page.
> > >
> > > The deadline for this proposal will be Monday, December 2.
> > >
> > > Thanks in advance for feedback / comments.
> > >
> > > --Jens & Patrick
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Dave Barnes]

+1

On Fri, Nov 22, 2019 at 9:17 AM Kirk Lund  wrote:

> +1 yes!
>
> On Fri, Nov 22, 2019 at 9:15 AM Donal Evans  wrote:
>
> > +1
> >
> > Especially with the new management functionality on the way, this seems
> > like a good idea.
> >
> > On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao  wrote:
> >
> > > +100. Would be a great move.
> > >
> > > On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe 
> wrote:
> > >
> > > > Hello All,
> > > >
> > > > We'd like to propose moving gfsh and all associated commands into its
> > own
> > > > gradle submodule (implicitly thus also producing a separate maven
> > > > artifact). The underlying intent is to decouple geode core from any
> > > Spring
> > > > dependencies.
> > > >
> > > > The proposal is outlined here:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > >
> > > > Please provide feedback for this proposal *on this email thread* and
> > not
> > > in
> > > > the comment section of the proposal page.
> > > >
> > > > The deadline for this proposal will be Monday, December 2.
> > > >
> > > > Thanks in advance for feedback / comments.
> > > >
> > > > --Jens & Patrick
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Owen Nichols]

+1

It makes total sense that gfsh should depend on core, and core should be 
completely unaware of it.  The dependency untangling that results will also 
help pave the way for other interfaces, such as a gfsh-free management REST 
interface.


> On Nov 22, 2019, at 8:45 AM, Jinmei Liao  wrote:
> 
> +100. Would be a great move.
> 
> On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe  wrote:
> 
>> Hello All,
>> 
>> We'd like to propose moving gfsh and all associated commands into its own
>> gradle submodule (implicitly thus also producing a separate maven
>> artifact). The underlying intent is to decouple geode core from any Spring
>> dependencies.
>> 
>> The proposal is outlined here:
>> 
>> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
>> 
>> Please provide feedback for this proposal *on this email thread* and not in
>> the comment section of the proposal page.
>> 
>> The deadline for this proposal will be Monday, December 2.
>> 
>> Thanks in advance for feedback / comments.
>> 
>> --Jens & Patrick
>> 
> 
> 
> -- 
> Cheers
> 
> Jinmei

Re: [DISCUSS] - Move gfsh into its own submodule

[Dan Smith]

+1

Awesome!!!

-Dan

On Fri, Nov 22, 2019 at 9:33 AM Owen Nichols  wrote:

> +1
>
> It makes total sense that gfsh should depend on core, and core should be
> completely unaware of it.  The dependency untangling that results will also
> help pave the way for other interfaces, such as a gfsh-free management REST
> interface.
>
>
> > On Nov 22, 2019, at 8:45 AM, Jinmei Liao  wrote:
> >
> > +100. Would be a great move.
> >
> > On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe  wrote:
> >
> >> Hello All,
> >>
> >> We'd like to propose moving gfsh and all associated commands into its
> own
> >> gradle submodule (implicitly thus also producing a separate maven
> >> artifact). The underlying intent is to decouple geode core from any
> Spring
> >> dependencies.
> >>
> >> The proposal is outlined here:
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> >>
> >> Please provide feedback for this proposal *on this email thread* and
> not in
> >> the comment section of the proposal page.
> >>
> >> The deadline for this proposal will be Monday, December 2.
> >>
> >> Thanks in advance for feedback / comments.
> >>
> >> --Jens & Patrick
> >>
> >
> >
> > --
> > Cheers
> >
> > Jinmei
>
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Joey McAllister]

+1 !!

On Fri, Nov 22, 2019 at 9:42 AM Dan Smith  wrote:

> +1
>
> Awesome!!!
>
> -Dan
>
> On Fri, Nov 22, 2019 at 9:33 AM Owen Nichols  wrote:
>
> > +1
> >
> > It makes total sense that gfsh should depend on core, and core should be
> > completely unaware of it.  The dependency untangling that results will
> also
> > help pave the way for other interfaces, such as a gfsh-free management
> REST
> > interface.
> >
> >
> > > On Nov 22, 2019, at 8:45 AM, Jinmei Liao  wrote:
> > >
> > > +100. Would be a great move.
> > >
> > > On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe 
> wrote:
> > >
> > >> Hello All,
> > >>
> > >> We'd like to propose moving gfsh and all associated commands into its
> > own
> > >> gradle submodule (implicitly thus also producing a separate maven
> > >> artifact). The underlying intent is to decouple geode core from any
> > Spring
> > >> dependencies.
> > >>
> > >> The proposal is outlined here:
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > >>
> > >> Please provide feedback for this proposal *on this email thread* and
> > not in
> > >> the comment section of the proposal page.
> > >>
> > >> The deadline for this proposal will be Monday, December 2.
> > >>
> > >> Thanks in advance for feedback / comments.
> > >>
> > >> --Jens & Patrick
> > >>
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> >
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Bruce Schuchardt]

+1 great idea!

On 11/22/19 8:39 AM, Jens Deppe wrote:

Hello All,

We'd like to propose moving gfsh and all associated commands into its own
gradle submodule (implicitly thus also producing a separate maven
artifact). The underlying intent is to decouple geode core from any Spring
dependencies.

The proposal is outlined here:
https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project

Please provide feedback for this proposal *on this email thread* and not in
the comment section of the proposal page.

The deadline for this proposal will be Monday, December 2.

Thanks in advance for feedback / comments.

--Jens & Patrick

Re: DistributionArchUnitTest OutOfMemoryError

[Kirk Lund]

LoggingDependenciesTest is also an archunit test in geode-core. I'm going
to move LoggingDependenciesTest to integrationTest -- testing the direction
of dependency between two geode modules seems to fit the definition of
"integration".

On Thu, Nov 21, 2019 at 12:09 PM Dan Smith  wrote:

> We've disabled this test for now, so you shouldn't get an OOME with the
> latest develop.
>
> -Dan
>
> On Wed, Nov 20, 2019, 4:55 PM Michael Oleske  wrote:
>
> > I've hit the same error as Kirk.  My lazy solution was to just rerun
> > `./gradlew build` cause that would pass on the second time.
> >
> > -michael
> >
> > On Wed, Nov 20, 2019 at 4:53 PM Dan Smith  wrote:
> >
> > > We recently added this test. It passes for me, but I will look into it.
> > It
> > > is scanning classes, so that may be your oome.
> > >
> > > On Wed, Nov 20, 2019, 4:00 PM Kirk Lund  wrote:
> > >
> > > > Any ideas why DistributionArchUnitTest would run OutOfMemoryError
> when
> > > > doing a "./gradlew build"?
> > > >
> > > > I think we should move any unit tests that run OutOfMemoryError out
> of
> > > unit
> > > > tests (to integration tests maybe?).
> > > >
> > > > > Task :geode:geode-core:test
> > > > Heap dump file created [957877145 bytes in 17.227 secs]
> > > >
> > > > org.apache.geode.distributed.internal.DistributionArchUnitTest >
> > > > classMethod FAILED
> > > > java.lang.OutOfMemoryError: GC overhead limit exceeded
> > > >
> > > > 6991 tests completed, 1 failed, 12 skipped
> > > >
> > >
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Ernest Burghardt]

+1

On Fri, Nov 22, 2019 at 8:41 AM Jens Deppe  wrote:

> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode core from any Spring
> dependencies.
>
> The proposal is outlined here:
>
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
>
> Please provide feedback for this proposal *on this email thread* and not in
> the comment section of the proposal page.
>
> The deadline for this proposal will be Monday, December 2.
>
> Thanks in advance for feedback / comments.
>
> --Jens & Patrick
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Robert Houghton]

+1

Do we want to restart from my lazy POC from a few months ago?

On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:

> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode core from any Spring
> dependencies.
>
> The proposal is outlined here:
>
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
>
> Please provide feedback for this proposal *on this email thread* and not in
> the comment section of the proposal page.
>
> The deadline for this proposal will be Monday, December 2.
>
> Thanks in advance for feedback / comments.
>
> --Jens & Patrick
>

PR jobs failing to start

[Kirk Lund]

FYI: Looks like all PR test and build jobs are failing with:

Warning: Permanently added '10.0.0.61' (ECDSA) to the list of known hosts.
ServerAliveCountMax=5: No such file or directory
capture-call-stacks.sh

Re: PR jobs failing to start

[Robert Houghton]

This was me. I merged a CI change that was missing an SSH option flag. We
need to override the PR merge check to fix. I have paused PR jobs until
then.

On Fri, Nov 22, 2019 at 11:52 AM Kirk Lund  wrote:

> FYI: Looks like all PR test and build jobs are failing with:
>
> Warning: Permanently added '10.0.0.61' (ECDSA) to the list of known hosts.
> ServerAliveCountMax=5: No such file or directory
> capture-call-stacks.sh
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Owen Nichols]

Tallying the votes from this thread, it looks like the majority vote is to 
NEVER allow override even in extreme circumstance.

Naba: -1
Donal: -1
Dan: +1
Udo: +1 (extreme circumstances beyond 99.9% case)
Juan: -1
Ben: +1 (emergency 'break glass’)
Mark: -1 


> On Oct 31, 2019, at 10:17 AM, Udo Kohlmeyer  wrote:
> 
> You are correct... Break glass is a sign that whatever needed to be done, was 
> not going to work using the prescribed approach..
> 
> I see this "break glass" as a special handshake or someone with more 
> "authority" needs to be agree with this... but given there is not "someone 
> with more authority" in Apache... this would have to be consensus between 
> either committers or PMC members.
> 
> --Udo
> 
> On 10/31/19 9:58 AM, Mark Hanson wrote:
>> -1 for "Break glass" approach. Needing a break glass approach is a sign. I 
>> wonder how hard that would be to make exist. I think our break glass 
>> approach is that we have someone with the power disable the restrictions in 
>> Github for the window that we must and then we put it back.
>> 
>> Thanks,
>> Mark
>> 
>>> On Oct 31, 2019, at 9:26 AM, Benjamin Ross  wrote:
>>> 
>>> I would agree with udo, +1 to having an emergency 'break glass' override
>>> but -1 to having the ability to do it routinely or for convenience.
>>> 
>>> The main use case in my mind is for infrastructure related issues that
>>> block a PR behind unrelated changes which can be really frustrating and
>>> inconvenient (StressNewTest is a big culprit here) but I'm hoping that if
>>> constant issues with this arise it will lead to fixing the offending
>>> infrastructure, whether that means changing test itself or the architecture
>>> in which it runs, to make our pipelines more reliable. If we smooth over
>>> PR's that run into issues every time Stress Tests break a test which only
>>> had logging changes (or similar situations) then there's no incentive for
>>> us to improve the Stress Tests job.
>>> 
>>> Having said all that, being completely without the ability to perform an
>>> emergency override if everything goes sideways and the only way to fix it
>>> is to push a commit which can't get a green pipeline seems like a pretty
>>> good idea to me as long as we all agree on what circumstances qualify as an
>>> emergency.
>>> 
>>> On Thu, Oct 31, 2019 at 2:43 AM Ju@N  wrote:
>>> 
 -1 for allowing overrides.
 If there's an edge case on which it's required, then we could use it at the
 very last resources *if and only if* it's been discussed and approved
 through the dev list for that particular case.
 Cheers.
 
 
 On Wed, Oct 30, 2019 at 11:35 PM Robert Houghton 
 wrote:
 
> Any committer has the 'status' permission on apache/geode.git. Some API
> tokens have it as well. Its curl + github API reasoning to do this.
> 
> On Wed, Oct 30, 2019 at 2:02 PM Jason Huynh  wrote:
> 
>> If we are going to allow overrides, then maybe what Owen is describing
>> should occur.  Make a request on the dev list and explain the
 reasoning.
>> I don't think this has been done and a few have already been
 overridden.
>> Also who has the capability to override and knows how.  How is that
>> determined?
>> 
>> On Wed, Oct 30, 2019 at 1:59 PM Owen Nichols 
> wrote:
 How do you override a check, anyway?
>>> Much like asking for jira permissions, wiki permissions, etc, just
 ask
> on
>>> the dev list ;)
>>> 
>>> Presumably this type of request would be made as a “last resort”
>> following
>>> a dev list discussion wherein all other reasonable options had been
>>> exhausted (reworking or splitting up the PR, pushing empty commits,
>>> rebasing the PR, etc)
>>> 
 On Oct 30, 2019, at 1:42 PM, Dan Smith  wrote:
 
 +1 for allowing overrides. I think we should avoid backing
 ourselves
>>> into a
 corner where we can't get anything into develop without talking to
>> apache
 infra. Some infrastructure things we can't even fix without
 pushing a
 change develop!
 
 How do you override a check, anyway?
 
 -Dan
 
 On Wed, Oct 30, 2019 at 12:58 PM Donal Evans 
>> wrote:
> -1 to overriding from me.
> 
> The question I have here is what's the rush? Is anything ever so
> time-sensitive that you can't even wait the 15 minutes it takes
 for
> it
>>> to
> build and run unit tests? If some infrastructure problem is
> preventing
> builds or tests from completing then that should be fixed before
 any
>> new
> changes are added, otherwise what's the point in even having the
 pre
> check-in process?
> 
> -Donal
> 
> On Wed, Oct 30, 2019 at 11:44 AM Nabarun Nag 
> wrote:
>> @Aaron
>> It's okay to wait for at lea

[VOTE] Fix bad-merge of GEODE-7488

[Robert Houghton]

I was overzealous in a merge to Geode, and got us into a chicken-and-egg
issue for PRs and reverts. Calling a vote to override the GitHub merge
button restriction via commiter privileges, to merge the fix in
https://github.com/apache/geode/pull/4360

Re: [VOTE] Fix bad-merge of GEODE-7488

[Anthony Baker]

Clearly the right thing to do is fix it.  VOTE not needed IMO.

Anthony


> On Nov 22, 2019, at 11:55 AM, Robert Houghton  wrote:
> 
> I was overzealous in a merge to Geode, and got us into a chicken-and-egg
> issue for PRs and reverts. Calling a vote to override the GitHub merge
> button restriction via commiter privileges, to merge the fix in
> https://github.com/apache/geode/pull/4360

Re: [VOTE] Fix bad-merge of GEODE-7488

[Owen Nichols]

It would set a bad precedent to circumvent without due process a decision that 
was agreed by the Geode community 
.

> On Nov 22, 2019, at 12:00 PM, Anthony Baker  wrote:
> 
> Clearly the right thing to do is fix it.  VOTE not needed IMO.
> 
> Anthony
> 
> 
>> On Nov 22, 2019, at 11:55 AM, Robert Houghton  wrote:
>> 
>> I was overzealous in a merge to Geode, and got us into a chicken-and-egg
>> issue for PRs and reverts. Calling a vote to override the GitHub merge
>> button restriction via commiter privileges, to merge the fix in
>> https://github.com/apache/geode/pull/4360
> 

Re: [VOTE] Fix bad-merge of GEODE-7488

[Nabarun Nag]

+1

On Fri, Nov 22, 2019 at 12:00 PM Anthony Baker  wrote:

> Clearly the right thing to do is fix it.  VOTE not needed IMO.
>
> Anthony
>
>
> > On Nov 22, 2019, at 11:55 AM, Robert Houghton 
> wrote:
> >
> > I was overzealous in a merge to Geode, and got us into a chicken-and-egg
> > issue for PRs and reverts. Calling a vote to override the GitHub merge
> > button restriction via commiter privileges, to merge the fix in
> > https://github.com/apache/geode/pull/4360
>
>

Re: [VOTE] Fix bad-merge of GEODE-7488

[Dan Smith]

+1 Go for it.

-Dan

On Fri, Nov 22, 2019 at 12:07 PM Owen Nichols  wrote:

> It would set a bad precedent to circumvent without due process a decision
> that was agreed by the Geode community <
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> >.
>
> > On Nov 22, 2019, at 12:00 PM, Anthony Baker  wrote:
> >
> > Clearly the right thing to do is fix it.  VOTE not needed IMO.
> >
> > Anthony
> >
> >
> >> On Nov 22, 2019, at 11:55 AM, Robert Houghton 
> wrote:
> >>
> >> I was overzealous in a merge to Geode, and got us into a chicken-and-egg
> >> issue for PRs and reverts. Calling a vote to override the GitHub merge
> >> button restriction via commiter privileges, to merge the fix in
> >> https://github.com/apache/geode/pull/4360
> >
>
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Kirk Lund]

Does everyone realize that you just voted NO to what now needs to be done
for "[VOTE] Fix bad-merge of GEODE-7488"?

So right now, if we do not override the PR check, we have no way to fix the
PR checks.

On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:

> Tallying the votes from this thread, it looks like the majority vote is to
> NEVER allow override even in extreme circumstance.
>
> Naba: -1
> Donal: -1
> Dan: +1
> Udo: +1 (extreme circumstances beyond 99.9% case)
> Juan: -1
> Ben: +1 (emergency 'break glass’)
> Mark: -1
>
>
> > On Oct 31, 2019, at 10:17 AM, Udo Kohlmeyer  wrote:
> >
> > You are correct... Break glass is a sign that whatever needed to be
> done, was not going to work using the prescribed approach..
> >
> > I see this "break glass" as a special handshake or someone with more
> "authority" needs to be agree with this... but given there is not "someone
> with more authority" in Apache... this would have to be consensus between
> either committers or PMC members.
> >
> > --Udo
> >
> > On 10/31/19 9:58 AM, Mark Hanson wrote:
> >> -1 for "Break glass" approach. Needing a break glass approach is a
> sign. I wonder how hard that would be to make exist. I think our break
> glass approach is that we have someone with the power disable the
> restrictions in Github for the window that we must and then we put it back.
> >>
> >> Thanks,
> >> Mark
> >>
> >>> On Oct 31, 2019, at 9:26 AM, Benjamin Ross  wrote:
> >>>
> >>> I would agree with udo, +1 to having an emergency 'break glass'
> override
> >>> but -1 to having the ability to do it routinely or for convenience.
> >>>
> >>> The main use case in my mind is for infrastructure related issues that
> >>> block a PR behind unrelated changes which can be really frustrating and
> >>> inconvenient (StressNewTest is a big culprit here) but I'm hoping that
> if
> >>> constant issues with this arise it will lead to fixing the offending
> >>> infrastructure, whether that means changing test itself or the
> architecture
> >>> in which it runs, to make our pipelines more reliable. If we smooth
> over
> >>> PR's that run into issues every time Stress Tests break a test which
> only
> >>> had logging changes (or similar situations) then there's no incentive
> for
> >>> us to improve the Stress Tests job.
> >>>
> >>> Having said all that, being completely without the ability to perform
> an
> >>> emergency override if everything goes sideways and the only way to fix
> it
> >>> is to push a commit which can't get a green pipeline seems like a
> pretty
> >>> good idea to me as long as we all agree on what circumstances qualify
> as an
> >>> emergency.
> >>>
> >>> On Thu, Oct 31, 2019 at 2:43 AM Ju@N  wrote:
> >>>
>  -1 for allowing overrides.
>  If there's an edge case on which it's required, then we could use it
> at the
>  very last resources *if and only if* it's been discussed and approved
>  through the dev list for that particular case.
>  Cheers.
> 
> 
>  On Wed, Oct 30, 2019 at 11:35 PM Robert Houghton <
> rhough...@pivotal.io>
>  wrote:
> 
> > Any committer has the 'status' permission on apache/geode.git. Some
> API
> > tokens have it as well. Its curl + github API reasoning to do this.
> >
> > On Wed, Oct 30, 2019 at 2:02 PM Jason Huynh 
> wrote:
> >
> >> If we are going to allow overrides, then maybe what Owen is
> describing
> >> should occur.  Make a request on the dev list and explain the
>  reasoning.
> >> I don't think this has been done and a few have already been
>  overridden.
> >> Also who has the capability to override and knows how.  How is that
> >> determined?
> >>
> >> On Wed, Oct 30, 2019 at 1:59 PM Owen Nichols 
> > wrote:
>  How do you override a check, anyway?
> >>> Much like asking for jira permissions, wiki permissions, etc, just
>  ask
> > on
> >>> the dev list ;)
> >>>
> >>> Presumably this type of request would be made as a “last resort”
> >> following
> >>> a dev list discussion wherein all other reasonable options had been
> >>> exhausted (reworking or splitting up the PR, pushing empty commits,
> >>> rebasing the PR, etc)
> >>>
>  On Oct 30, 2019, at 1:42 PM, Dan Smith  wrote:
> 
>  +1 for allowing overrides. I think we should avoid backing
>  ourselves
> >>> into a
>  corner where we can't get anything into develop without talking to
> >> apache
>  infra. Some infrastructure things we can't even fix without
>  pushing a
>  change develop!
> 
>  How do you override a check, anyway?
> 
>  -Dan
> 
>  On Wed, Oct 30, 2019 at 12:58 PM Donal Evans 
> >> wrote:
> > -1 to overriding from me.
> >
> > The question I have here is what's the rush? Is anything ever so
> > time-sensitive that you can't even wait the 15 minutes it takes

Re: [DISCUSS] is overriding a PR check ever justified?

[Dan Smith]

On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:

> Tallying the votes from this thread, it looks like the majority vote is to
> NEVER allow override even in extreme circumstance.
>

I think a better way of summarizing this thread so far is that there isn't
really a consensus on this point, opinions seem to be fairly split. This
wasn't a vote, and not everybody who expressed an opinion put a number next
to their opinion or was directly aligned with the statement above.

Maybe folks who think there should not be an override option could propose
a specific process for dealing with issues like what Robert just did and
try to bring the rest of us on board with that?

-Dan

Re: [VOTE] Fix bad-merge of GEODE-7488

[Donal Evans]

+1

While I'm against overriding PR checks in general, this is clearly a
special case.

On Fri, Nov 22, 2019 at 12:10 PM Nabarun Nag  wrote:

> +1
>
> On Fri, Nov 22, 2019 at 12:00 PM Anthony Baker  wrote:
>
> > Clearly the right thing to do is fix it.  VOTE not needed IMO.
> >
> > Anthony
> >
> >
> > > On Nov 22, 2019, at 11:55 AM, Robert Houghton 
> > wrote:
> > >
> > > I was overzealous in a merge to Geode, and got us into a
> chicken-and-egg
> > > issue for PRs and reverts. Calling a vote to override the GitHub merge
> > > button restriction via commiter privileges, to merge the fix in
> > > https://github.com/apache/geode/pull/4360
> >
> >
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Nabarun Nag]

Just out of curiosity, why did the PR checks for GEODE-7488 not fail and
allowed it be merged? Is something lacking in our testing?

On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:

> On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:
>
> > Tallying the votes from this thread, it looks like the majority vote is
> to
> > NEVER allow override even in extreme circumstance.
> >
>
> I think a better way of summarizing this thread so far is that there isn't
> really a consensus on this point, opinions seem to be fairly split. This
> wasn't a vote, and not everybody who expressed an opinion put a number next
> to their opinion or was directly aligned with the statement above.
>
> Maybe folks who think there should not be an override option could propose
> a specific process for dealing with issues like what Robert just did and
> try to bring the rest of us on board with that?
>
> -Dan
>

Re: [VOTE] Fix bad-merge of GEODE-7488

[Kirk Lund]

+1 adding my vote

On Fri, Nov 22, 2019 at 11:56 AM Robert Houghton 
wrote:

> I was overzealous in a merge to Geode, and got us into a chicken-and-egg
> issue for PRs and reverts. Calling a vote to override the GitHub merge
> button restriction via commiter privileges, to merge the fix in
> https://github.com/apache/geode/pull/4360
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Donal Evans]

In light of the recent issue with GEODE-7488, I think I should
clarify/expand what I said earlier in this thread. While I'm definitely
against bypassing PR checks when it's done just for convenience or
impatience, I agree with Ben and Udo's stance that in "emergencies" it
should be at least considered.

If something is broken in such a way that the ONLY way to fix it is to
force through a commit and bypass PR checks then there's not really an
argument against that. However, if it's a case of "X test is failing
because that test has underlying problems" or something similar, then the
solution should be to fix the test and improve the quality of our pipeline
rather than just sweep it under the rug.

On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:

> On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:
>
> > Tallying the votes from this thread, it looks like the majority vote is
> to
> > NEVER allow override even in extreme circumstance.
> >
>
> I think a better way of summarizing this thread so far is that there isn't
> really a consensus on this point, opinions seem to be fairly split. This
> wasn't a vote, and not everybody who expressed an opinion put a number next
> to their opinion or was directly aligned with the statement above.
>
> Maybe folks who think there should not be an override option could propose
> a specific process for dealing with issues like what Robert just did and
> try to bring the rest of us on board with that?
>
> -Dan
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Udo Kohlmeyer]

@Naba.. wrong thread :)

We have real scenario here now, where we have no consensus on whether we 
are allowed or not allowed to override.. Do we vote now? OR do we apply 
common sense?


TBH, at this junction we should really just do whatever we believe is 
correct. A committer is appointed due to trust, so we should trust that 
our committers will do the right thing.


But the same trust that our committers would always do the right thing 
has gotten us to this point where we don't trust


MUCH bigger chicken-and-egg problem.

I motion that we vote on this. I would also like to request all those 
AGAINST the override to provide strategies for us to not shoot-ourselves 
in the foot. (like Dan said)


--Udo

On 11/22/19 12:30 PM, Nabarun Nag wrote:

Just out of curiosity, why did the PR checks for GEODE-7488 not fail and
allowed it be merged? Is something lacking in our testing?

On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:


On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols  wrote:


Tallying the votes from this thread, it looks like the majority vote is

to

NEVER allow override even in extreme circumstance.


I think a better way of summarizing this thread so far is that there isn't
really a consensus on this point, opinions seem to be fairly split. This
wasn't a vote, and not everybody who expressed an opinion put a number next
to their opinion or was directly aligned with the statement above.

Maybe folks who think there should not be an override option could propose
a specific process for dealing with issues like what Robert just did and
try to bring the rest of us on board with that?

-Dan

Re: [VOTE] Fix bad-merge of GEODE-7488

[Udo Kohlmeyer]

No brainer vote for me. +1

@Donal, overrides should only EVER be for "break glass emergency". 
Anybody who would abuse it for any other reason, should seriously be 
considered "enemy-of-the-state".


--Udo

On 11/22/19 11:55 AM, Robert Houghton wrote:

I was overzealous in a merge to Geode, and got us into a chicken-and-egg
issue for PRs and reverts. Calling a vote to override the GitHub merge
button restriction via commiter privileges, to merge the fix in
https://github.com/apache/geode/pull/4360

Re: [DISCUSS] - Move gfsh into its own submodule

[Charlie Black]

this proposal == awesome sauce

+1

On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton 
wrote:

> +1
>
> Do we want to restart from my lazy POC from a few months ago?
>
> On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:
>
> > Hello All,
> >
> > We'd like to propose moving gfsh and all associated commands into its own
> > gradle submodule (implicitly thus also producing a separate maven
> > artifact). The underlying intent is to decouple geode core from any
> Spring
> > dependencies.
> >
> > The proposal is outlined here:
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> >
> > Please provide feedback for this proposal *on this email thread* and not
> in
> > the comment section of the proposal page.
> >
> > The deadline for this proposal will be Monday, December 2.
> >
> > Thanks in advance for feedback / comments.
> >
> > --Jens & Patrick
> >
>


-- 
Charlie Black | cbl...@pivotal.io

Re: [DISCUSS] - Move gfsh into its own submodule

[Nabarun Nag]

+1

On Fri, Nov 22, 2019 at 12:51 PM Charlie Black  wrote:

> this proposal == awesome sauce
>
> +1
>
> On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton 
> wrote:
>
> > +1
> >
> > Do we want to restart from my lazy POC from a few months ago?
> >
> > On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:
> >
> > > Hello All,
> > >
> > > We'd like to propose moving gfsh and all associated commands into its
> own
> > > gradle submodule (implicitly thus also producing a separate maven
> > > artifact). The underlying intent is to decouple geode core from any
> > Spring
> > > dependencies.
> > >
> > > The proposal is outlined here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > >
> > > Please provide feedback for this proposal *on this email thread* and
> not
> > in
> > > the comment section of the proposal page.
> > >
> > > The deadline for this proposal will be Monday, December 2.
> > >
> > > Thanks in advance for feedback / comments.
> > >
> > > --Jens & Patrick
> > >
> >
>
>
> --
> Charlie Black | cbl...@pivotal.io
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Jason Huynh]

@Udo - I think Naba was asking why the original commit that broke the
pipeline wasn't detected.

I think instead of a vote email, an email alerting the dev list that an
override needs to take place is still good to have.  If nothing else, to
identify areas that we might be able to improve with additional coverage or
checks.




On Fri, Nov 22, 2019 at 12:40 PM Udo Kohlmeyer 
wrote:

> @Naba.. wrong thread :)
>
> We have real scenario here now, where we have no consensus on whether we
> are allowed or not allowed to override.. Do we vote now? OR do we apply
> common sense?
>
> TBH, at this junction we should really just do whatever we believe is
> correct. A committer is appointed due to trust, so we should trust that
> our committers will do the right thing.
>
> But the same trust that our committers would always do the right thing
> has gotten us to this point where we don't trust
>
> MUCH bigger chicken-and-egg problem.
>
> I motion that we vote on this. I would also like to request all those
> AGAINST the override to provide strategies for us to not shoot-ourselves
> in the foot. (like Dan said)
>
> --Udo
>
> On 11/22/19 12:30 PM, Nabarun Nag wrote:
> > Just out of curiosity, why did the PR checks for GEODE-7488 not fail and
> > allowed it be merged? Is something lacking in our testing?
> >
> > On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:
> >
> >> On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols 
> wrote:
> >>
> >>> Tallying the votes from this thread, it looks like the majority vote is
> >> to
> >>> NEVER allow override even in extreme circumstance.
> >>>
> >> I think a better way of summarizing this thread so far is that there
> isn't
> >> really a consensus on this point, opinions seem to be fairly split. This
> >> wasn't a vote, and not everybody who expressed an opinion put a number
> next
> >> to their opinion or was directly aligned with the statement above.
> >>
> >> Maybe folks who think there should not be an override option could
> propose
> >> a specific process for dealing with issues like what Robert just did and
> >> try to bring the rest of us on board with that?
> >>
> >> -Dan
> >>
>

Re: Odg: Restart gateway-receiver

[Barry Oglesby]

> If we don't send any event, the connection will be closed after some time
as connection is inactive.

Are you seeing this behavior? I don't think this is true by default.

AbstractRemoteGatewaySender.initProxy sets these fields on the PoolFactory:

pf.setReadTimeout(this.socketReadTimeout);
pf.setIdleTimeout(connectionIdleTimeOut);

By default, socketReadTimeout is 0 (no timeout), and connectionIdleTimeOut
is -1 (disabled).

Each Event Processor thread will have its own connection to the remote site:

Event Processor for GatewaySender_ny.1:
GatewaySenderEventRemoteDispatcher.initializeConnection connection=Pooled
Connection to 127.0.0.1:5452: Connection[127.0.0.1:5452]@306907760
Event Processor for GatewaySender_ny.2:
GatewaySenderEventRemoteDispatcher.initializeConnection connection=Pooled
Connection to 127.0.0.1:5452: Connection[127.0.0.1:5452]@608855137
Event Processor for GatewaySender_ny.0:
GatewaySenderEventRemoteDispatcher.initializeConnection connection=Pooled
Connection to 127.0.0.1:5452: Connection[127.0.0.1:5452]@950613560
Event Processor for GatewaySender_ny.4:
GatewaySenderEventRemoteDispatcher.initializeConnection connection=Pooled
Connection to 127.0.0.1:5452: Connection[127.0.0.1:5452]@1005378489
Event Processor for GatewaySender_ny.3:
GatewaySenderEventRemoteDispatcher.initializeConnection connection=Pooled
Connection to 127.0.0.1:5452: Connection[127.0.0.1:5452]@629246640

There will be one Event Processor thread for each dispatcher thread (5 by
default).

There aren't any good public ways to monitor the connections other than JMX.

One way to monitor these connections is with ConnectionStats on the sender
side.

You can do that with vsd: ClientStats -> GatewaySenderStats -> connections

You can also do it with code like:

private int getConnectionCount(String gatewaySenderId) {
  AbstractGatewaySender sender = (AbstractGatewaySender)
cache.getGatewaySender(gatewaySenderId);
  int totalConnections = 0;
  if (sender != null) {
for (ConnectionStats connectionStats :
sender.getProxy().getEndpointManager().getAllStats().values()) {
  totalConnections += connectionStats.getConnections();
}
System.out.println("Sender=" + gatewaySenderId + "; connectionCount=" +
totalConnections);
  }
  return totalConnections;
}

You can also dump whether the dispatcher is connected like:

private void dumpConnected(String gatewaySenderId) {
  AbstractGatewaySender sender = (AbstractGatewaySender)
cache.getGatewaySender(gatewaySenderId);
  if (sender.isParallel()) {
ConcurrentParallelGatewaySenderEventProcessor concurrentProcessor =
(ConcurrentParallelGatewaySenderEventProcessor) sender.getEventProcessor();
for (ParallelGatewaySenderEventProcessor processor :
concurrentProcessor.getProcessors()) {
  System.out.println("Processor=" + processor + "; isConnected=" +
processor.getDispatcher().isConnectedToRemote());
}
  } else {
ConcurrentSerialGatewaySenderEventProcessor concurrentProcessor =
(ConcurrentSerialGatewaySenderEventProcessor) sender.getEventProcessor();
List processors =
concurrentProcessor.getProcessors();
for (SerialGatewaySenderEventProcessor processor :
concurrentProcessor.getProcessors()) {
  System.out.println("Processor=" + processor + "; isConnected=" +
processor.getDispatcher().isConnectedToRemote());
}
  }
}

The isConnectedToRemote method does:

return connection != null && !connection.isDestroyed();

Thanks,
Barry Oglesby



On Thu, Nov 21, 2019 at 11:15 PM Mario Kevo  wrote:

> Hi,
>
> @Barry Oglesby , thanks for the clarification.
>
> If we don't send any event, the connection will be closed after some time
> as connection is inactive.
> Is it possible to somehow monitor from the app if the replication is
> established to get information if there is a some problem with network or
> it is just closed due to inactivity?
> Can we monitor the replication on some other way than looking
> "isConnected" state on JMX?
>
> BR,
> Mario
> --
> *Šalje:* Barry Oglesby 
> *Poslano:* 14. studenog 2019. 18:29
> *Prima:* dev@geode.apache.org 
> *Predmet:* Re: Restart gateway-receiver
>
> Mario,
>
> Thats the current behavior. When the sender is initially started, it
> attempts to connect to the receiver. If it does not connect, it won't retry
> until there is a batch of events to send. Look for callers of
> GatewaySenderEventRemoteDispatcher.initializeConnection to see the
> behavior. It could be changed to have a task to retry lost connections, but
> generally there are events in the queue, so the connection is
> re-established pretty quickly by the event processor thread.
>
> Thanks,
> Barry Oglesby
>
>
>
> On Wed, Nov 13, 2019 at 4:55 AM Mario Kevo  wrote:
>
> > Hi geode dev,
> >
> > After creating gateways senders and receivers between two geode clusters
> > replications is established. After restart gateway receiver, sender will
> > not connect to it until we send some entry from sender to receiver.
> > Is this a normal

Re: [DISCUSS] - Move gfsh into its own submodule

[Mark Bretl]

+1

On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag  wrote:

> +1
>
> On Fri, Nov 22, 2019 at 12:51 PM Charlie Black  wrote:
>
> > this proposal == awesome sauce
> >
> > +1
> >
> > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton 
> > wrote:
> >
> > > +1
> > >
> > > Do we want to restart from my lazy POC from a few months ago?
> > >
> > > On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:
> > >
> > > > Hello All,
> > > >
> > > > We'd like to propose moving gfsh and all associated commands into its
> > own
> > > > gradle submodule (implicitly thus also producing a separate maven
> > > > artifact). The underlying intent is to decouple geode core from any
> > > Spring
> > > > dependencies.
> > > >
> > > > The proposal is outlined here:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > >
> > > > Please provide feedback for this proposal *on this email thread* and
> > not
> > > in
> > > > the comment section of the proposal page.
> > > >
> > > > The deadline for this proposal will be Monday, December 2.
> > > >
> > > > Thanks in advance for feedback / comments.
> > > >
> > > > --Jens & Patrick
> > > >
> > >
> >
> >
> > --
> > Charlie Black | cbl...@pivotal.io
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Jason Huynh]

+1
I think we are now at +114 thanks to jinmei's 100 ;-)


On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl  wrote:

> +1
>
> On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag  wrote:
>
> > +1
> >
> > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black 
> wrote:
> >
> > > this proposal == awesome sauce
> > >
> > > +1
> > >
> > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton  >
> > > wrote:
> > >
> > > > +1
> > > >
> > > > Do we want to restart from my lazy POC from a few months ago?
> > > >
> > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe  wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > > We'd like to propose moving gfsh and all associated commands into
> its
> > > own
> > > > > gradle submodule (implicitly thus also producing a separate maven
> > > > > artifact). The underlying intent is to decouple geode core from any
> > > > Spring
> > > > > dependencies.
> > > > >
> > > > > The proposal is outlined here:
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > > >
> > > > > Please provide feedback for this proposal *on this email thread*
> and
> > > not
> > > > in
> > > > > the comment section of the proposal page.
> > > > >
> > > > > The deadline for this proposal will be Monday, December 2.
> > > > >
> > > > > Thanks in advance for feedback / comments.
> > > > >
> > > > > --Jens & Patrick
> > > > >
> > > >
> > >
> > >
> > > --
> > > Charlie Black | cbl...@pivotal.io
> > >
> >
>

Re: [DISCUSS] is overriding a PR check ever justified?

[Udo Kohlmeyer]

@Jason, thank you for clarification.. I just pointed out to @Naba that 
it was the wrong thread. As, like in many cases, the original intent of 
the thread is lost because someone has asked a question, not directly 
relating to the thread and then the whole thread is derailed.


When I asked for a vote, I was asking should we be voting on whether we 
should allow overrides. It was inconclusive, with 4 against and 3 for 
overrides. Which really leaves us in a position where some feel we 
should allow the "break glass emergency" override of branch protection 
and some don't, and the rest of the 90+ committers who don't care.


Are you suggesting that every override now becomes a vote on the dev 
list? Given that we don't have a real stance on whether we allow it or 
not, maybe that is best UNTIL we hit a scenario where we cannot get 
consensus on the override.


--Udo

On 11/22/19 1:06 PM, Jason Huynh wrote:

@Udo - I think Naba was asking why the original commit that broke the
pipeline wasn't detected.

I think instead of a vote email, an email alerting the dev list that an
override needs to take place is still good to have.  If nothing else, to
identify areas that we might be able to improve with additional coverage or
checks.




On Fri, Nov 22, 2019 at 12:40 PM Udo Kohlmeyer 
wrote:


@Naba.. wrong thread :)

We have real scenario here now, where we have no consensus on whether we
are allowed or not allowed to override.. Do we vote now? OR do we apply
common sense?

TBH, at this junction we should really just do whatever we believe is
correct. A committer is appointed due to trust, so we should trust that
our committers will do the right thing.

But the same trust that our committers would always do the right thing
has gotten us to this point where we don't trust

MUCH bigger chicken-and-egg problem.

I motion that we vote on this. I would also like to request all those
AGAINST the override to provide strategies for us to not shoot-ourselves
in the foot. (like Dan said)

--Udo

On 11/22/19 12:30 PM, Nabarun Nag wrote:

Just out of curiosity, why did the PR checks for GEODE-7488 not fail and
allowed it be merged? Is something lacking in our testing?

On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:


On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols 

wrote:

Tallying the votes from this thread, it looks like the majority vote is

to

NEVER allow override even in extreme circumstance.


I think a better way of summarizing this thread so far is that there

isn't

really a consensus on this point, opinions seem to be fairly split. This
wasn't a vote, and not everybody who expressed an opinion put a number

next

to their opinion or was directly aligned with the statement above.

Maybe folks who think there should not be an override option could

propose

a specific process for dealing with issues like what Robert just did and
try to bring the rest of us on board with that?

-Dan

Re: [DISCUSS] is overriding a PR check ever justified?

[Jason Huynh]

@Udo- I believe that just noticing how often we have to override, might
help influence what the correct decision or better yet, solution, might
be.  Not necessarily needing a vote email but just an email that describes
why we needed to override.  I think it will help us get a better
understanding of when we have had to override and might show us a trend
over time on what issues or areas we may better coverage in.  Personally
I'd prefer if we'd have to override less often and in the open when we do.

On Fri, Nov 22, 2019 at 2:02 PM Udo Kohlmeyer  wrote:

> @Jason, thank you for clarification.. I just pointed out to @Naba that
> it was the wrong thread. As, like in many cases, the original intent of
> the thread is lost because someone has asked a question, not directly
> relating to the thread and then the whole thread is derailed.
>
> When I asked for a vote, I was asking should we be voting on whether we
> should allow overrides. It was inconclusive, with 4 against and 3 for
> overrides. Which really leaves us in a position where some feel we
> should allow the "break glass emergency" override of branch protection
> and some don't, and the rest of the 90+ committers who don't care.
>
> Are you suggesting that every override now becomes a vote on the dev
> list? Given that we don't have a real stance on whether we allow it or
> not, maybe that is best UNTIL we hit a scenario where we cannot get
> consensus on the override.
>
> --Udo
>
> On 11/22/19 1:06 PM, Jason Huynh wrote:
> > @Udo - I think Naba was asking why the original commit that broke the
> > pipeline wasn't detected.
> >
> > I think instead of a vote email, an email alerting the dev list that an
> > override needs to take place is still good to have.  If nothing else, to
> > identify areas that we might be able to improve with additional coverage
> or
> > checks.
> >
> >
> >
> >
> > On Fri, Nov 22, 2019 at 12:40 PM Udo Kohlmeyer 
> > wrote:
> >
> >> @Naba.. wrong thread :)
> >>
> >> We have real scenario here now, where we have no consensus on whether we
> >> are allowed or not allowed to override.. Do we vote now? OR do we apply
> >> common sense?
> >>
> >> TBH, at this junction we should really just do whatever we believe is
> >> correct. A committer is appointed due to trust, so we should trust that
> >> our committers will do the right thing.
> >>
> >> But the same trust that our committers would always do the right thing
> >> has gotten us to this point where we don't trust
> >>
> >> MUCH bigger chicken-and-egg problem.
> >>
> >> I motion that we vote on this. I would also like to request all those
> >> AGAINST the override to provide strategies for us to not shoot-ourselves
> >> in the foot. (like Dan said)
> >>
> >> --Udo
> >>
> >> On 11/22/19 12:30 PM, Nabarun Nag wrote:
> >>> Just out of curiosity, why did the PR checks for GEODE-7488 not fail
> and
> >>> allowed it be merged? Is something lacking in our testing?
> >>>
> >>> On Fri, Nov 22, 2019 at 12:19 PM Dan Smith  wrote:
> >>>
>  On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols 
> >> wrote:
> > Tallying the votes from this thread, it looks like the majority vote
> is
>  to
> > NEVER allow override even in extreme circumstance.
> >
>  I think a better way of summarizing this thread so far is that there
> >> isn't
>  really a consensus on this point, opinions seem to be fairly split.
> This
>  wasn't a vote, and not everybody who expressed an opinion put a number
> >> next
>  to their opinion or was directly aligned with the statement above.
> 
>  Maybe folks who think there should not be an override option could
> >> propose
>  a specific process for dealing with issues like what Robert just did
> and
>  try to bring the rest of us on board with that?
> 
>  -Dan
> 
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Alexander Murmann]

+1

If we get to 200, the refactor implements itself, right?

On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh  wrote:

> +1
> I think we are now at +114 thanks to jinmei's 100 ;-)
>
>
> On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl  wrote:
>
> > +1
> >
> > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag  wrote:
> >
> > > +1
> > >
> > > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black 
> > wrote:
> > >
> > > > this proposal == awesome sauce
> > > >
> > > > +1
> > > >
> > > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Do we want to restart from my lazy POC from a few months ago?
> > > > >
> > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe 
> wrote:
> > > > >
> > > > > > Hello All,
> > > > > >
> > > > > > We'd like to propose moving gfsh and all associated commands into
> > its
> > > > own
> > > > > > gradle submodule (implicitly thus also producing a separate maven
> > > > > > artifact). The underlying intent is to decouple geode core from
> any
> > > > > Spring
> > > > > > dependencies.
> > > > > >
> > > > > > The proposal is outlined here:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > > > >
> > > > > > Please provide feedback for this proposal *on this email thread*
> > and
> > > > not
> > > > > in
> > > > > > the comment section of the proposal page.
> > > > > >
> > > > > > The deadline for this proposal will be Monday, December 2.
> > > > > >
> > > > > > Thanks in advance for feedback / comments.
> > > > > >
> > > > > > --Jens & Patrick
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Charlie Black | cbl...@pivotal.io
> > > >
> > >
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Charlie Black]

Just to see if the refactor happens by itself...

+200


On Fri, Nov 22, 2019 at 3:10 PM Alexander Murmann 
wrote:

> +1
>
> If we get to 200, the refactor implements itself, right?
>
> On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh  wrote:
>
> > +1
> > I think we are now at +114 thanks to jinmei's 100 ;-)
> >
> >
> > On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl  wrote:
> >
> > > +1
> > >
> > > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag  wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black 
> > > wrote:
> > > >
> > > > > this proposal == awesome sauce
> > > > >
> > > > > +1
> > > > >
> > > > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton <
> > rhough...@pivotal.io
> > > >
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Do we want to restart from my lazy POC from a few months ago?
> > > > > >
> > > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe 
> > wrote:
> > > > > >
> > > > > > > Hello All,
> > > > > > >
> > > > > > > We'd like to propose moving gfsh and all associated commands
> into
> > > its
> > > > > own
> > > > > > > gradle submodule (implicitly thus also producing a separate
> maven
> > > > > > > artifact). The underlying intent is to decouple geode core from
> > any
> > > > > > Spring
> > > > > > > dependencies.
> > > > > > >
> > > > > > > The proposal is outlined here:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > > > > >
> > > > > > > Please provide feedback for this proposal *on this email
> thread*
> > > and
> > > > > not
> > > > > > in
> > > > > > > the comment section of the proposal page.
> > > > > > >
> > > > > > > The deadline for this proposal will be Monday, December 2.
> > > > > > >
> > > > > > > Thanks in advance for feedback / comments.
> > > > > > >
> > > > > > > --Jens & Patrick
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Charlie Black | cbl...@pivotal.io
> > > > >
> > > >
> > >
> >
>


-- 
Charlie Black | cbl...@pivotal.io

Re: [DISCUSS] is overriding a PR check ever justified?

[Robert Houghton]

Answering here, because it was asked:
@nnag This commit was allowed to merge because we test 'geode' code in the
PR pipeline, but we do not test the CI structure and scripts. This is to
protect the infrastructure from being hijacked to do things like mine
bitcoin, operate as a botnet, etc. The CI directory is what defined WHAT
runs, and HOW (what infrastructure, instance size, etc). So the CI used in
PR pipeline is from the develop branch.

So a PR was filed that could not have found this bug, and it was merged.
Then all future PRs use that bad CI script, and nothing ever passes again.

On Fri, Nov 22, 2019, 14:19 Jason Huynh  wrote:

> @Udo- I believe that just noticing how often we have to override, might
> help influence what the correct decision or better yet, solution, might
> be.  Not necessarily needing a vote email but just an email that describes
> why we needed to override.  I think it will help us get a better
> understanding of when we have had to override and might show us a trend
> over time on what issues or areas we may better coverage in.  Personally
> I'd prefer if we'd have to override less often and in the open when we do.
>
> On Fri, Nov 22, 2019 at 2:02 PM Udo Kohlmeyer  wrote:
>
> > @Jason, thank you for clarification.. I just pointed out to @Naba that
> > it was the wrong thread. As, like in many cases, the original intent of
> > the thread is lost because someone has asked a question, not directly
> > relating to the thread and then the whole thread is derailed.
> >
> > When I asked for a vote, I was asking should we be voting on whether we
> > should allow overrides. It was inconclusive, with 4 against and 3 for
> > overrides. Which really leaves us in a position where some feel we
> > should allow the "break glass emergency" override of branch protection
> > and some don't, and the rest of the 90+ committers who don't care.
> >
> > Are you suggesting that every override now becomes a vote on the dev
> > list? Given that we don't have a real stance on whether we allow it or
> > not, maybe that is best UNTIL we hit a scenario where we cannot get
> > consensus on the override.
> >
> > --Udo
> >
> > On 11/22/19 1:06 PM, Jason Huynh wrote:
> > > @Udo - I think Naba was asking why the original commit that broke the
> > > pipeline wasn't detected.
> > >
> > > I think instead of a vote email, an email alerting the dev list that an
> > > override needs to take place is still good to have.  If nothing else,
> to
> > > identify areas that we might be able to improve with additional
> coverage
> > or
> > > checks.
> > >
> > >
> > >
> > >
> > > On Fri, Nov 22, 2019 at 12:40 PM Udo Kohlmeyer 
> > > wrote:
> > >
> > >> @Naba.. wrong thread :)
> > >>
> > >> We have real scenario here now, where we have no consensus on whether
> we
> > >> are allowed or not allowed to override.. Do we vote now? OR do we
> apply
> > >> common sense?
> > >>
> > >> TBH, at this junction we should really just do whatever we believe is
> > >> correct. A committer is appointed due to trust, so we should trust
> that
> > >> our committers will do the right thing.
> > >>
> > >> But the same trust that our committers would always do the right thing
> > >> has gotten us to this point where we don't trust
> > >>
> > >> MUCH bigger chicken-and-egg problem.
> > >>
> > >> I motion that we vote on this. I would also like to request all those
> > >> AGAINST the override to provide strategies for us to not
> shoot-ourselves
> > >> in the foot. (like Dan said)
> > >>
> > >> --Udo
> > >>
> > >> On 11/22/19 12:30 PM, Nabarun Nag wrote:
> > >>> Just out of curiosity, why did the PR checks for GEODE-7488 not fail
> > and
> > >>> allowed it be merged? Is something lacking in our testing?
> > >>>
> > >>> On Fri, Nov 22, 2019 at 12:19 PM Dan Smith 
> wrote:
> > >>>
> >  On Fri, Nov 22, 2019 at 11:56 AM Owen Nichols 
> > >> wrote:
> > > Tallying the votes from this thread, it looks like the majority
> vote
> > is
> >  to
> > > NEVER allow override even in extreme circumstance.
> > >
> >  I think a better way of summarizing this thread so far is that there
> > >> isn't
> >  really a consensus on this point, opinions seem to be fairly split.
> > This
> >  wasn't a vote, and not everybody who expressed an opinion put a
> number
> > >> next
> >  to their opinion or was directly aligned with the statement above.
> > 
> >  Maybe folks who think there should not be an override option could
> > >> propose
> >  a specific process for dealing with issues like what Robert just did
> > and
> >  try to bring the rest of us on board with that?
> > 
> >  -Dan
> > 
> >
>

Re: [DISCUSS] - Move gfsh into its own submodule

[Jens Deppe]

Most. Popular. Proposal. EVER!

On Fri, Nov 22, 2019 at 3:13 PM Charlie Black  wrote:

> Just to see if the refactor happens by itself...
>
> +200
>
>
> On Fri, Nov 22, 2019 at 3:10 PM Alexander Murmann 
> wrote:
>
> > +1
> >
> > If we get to 200, the refactor implements itself, right?
> >
> > On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh  wrote:
> >
> > > +1
> > > I think we are now at +114 thanks to jinmei's 100 ;-)
> > >
> > >
> > > On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl  wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black 
> > > > wrote:
> > > > >
> > > > > > this proposal == awesome sauce
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton <
> > > rhough...@pivotal.io
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > Do we want to restart from my lazy POC from a few months ago?
> > > > > > >
> > > > > > > On Fri, Nov 22, 2019, 08:40 Jens Deppe 
> > > wrote:
> > > > > > >
> > > > > > > > Hello All,
> > > > > > > >
> > > > > > > > We'd like to propose moving gfsh and all associated commands
> > into
> > > > its
> > > > > > own
> > > > > > > > gradle submodule (implicitly thus also producing a separate
> > maven
> > > > > > > > artifact). The underlying intent is to decouple geode core
> from
> > > any
> > > > > > > Spring
> > > > > > > > dependencies.
> > > > > > > >
> > > > > > > > The proposal is outlined here:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> > > > > > > >
> > > > > > > > Please provide feedback for this proposal *on this email
> > thread*
> > > > and
> > > > > > not
> > > > > > > in
> > > > > > > > the comment section of the proposal page.
> > > > > > > >
> > > > > > > > The deadline for this proposal will be Monday, December 2.
> > > > > > > >
> > > > > > > > Thanks in advance for feedback / comments.
> > > > > > > >
> > > > > > > > --Jens & Patrick
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Charlie Black | cbl...@pivotal.io
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Charlie Black | cbl...@pivotal.io
>