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

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

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

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

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

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

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

+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

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

@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

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

@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

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

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

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

+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

Re: Odg: Restart gateway-receiver

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

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

@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

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

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

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

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

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

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

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

@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

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

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

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

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

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

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

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

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

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

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,

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

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,

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

+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

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

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

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

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

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

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

[VOTE] Fix bad-merge of GEODE-7488

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?

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

Re: PR jobs failing to start

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

PR jobs failing to start

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] - Move gfsh into its own submodule

+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

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

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

Re: DistributionArchUnitTest OutOfMemoryError

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

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

+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

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

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

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

+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

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

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

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

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

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

+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

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

+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

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

+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

[DISCUSS] - Move gfsh into its own submodule

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: