Re: [DISCUSS] Tweak to branch protection rules

[Nabarun Nag]

+1

On Tue, Oct 29, 2019 at 6:21 PM Darrel Schneider 
wrote:

> +1
>
> On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols  wrote:
>
> > +1 …this has already bitten me a few times
> >
> > > On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> > >
> > > Hi all,
> > >
> > > It seems we've configured our branch protection rules such that
> pushing a
> > > change to a PR that has been approved invalidates the previous
> approval.
> > >
> > > I think we should turn this off - it looks like it's an optional
> feature.
> > > We should trust people to rerequest reviews if needed. Right now this
> is
> > > adding busywork for people to reapprove minor changes (Fixing merge
> > > conflicts, spotless, etc.)
> > >
> > > If you all agree I'll ask infra to uncheck "Dismiss stale pull request
> > > approvals when new commits are pushed." in our branch protection rules.
> > >
> > > -Dan
> >
> >
>

Re: [DISCUSS] Tweak to branch protection rules

[Darrel Schneider]

+1

On Tue, Oct 29, 2019 at 6:08 PM Owen Nichols  wrote:

> +1 …this has already bitten me a few times
>
> > On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> >
> > Hi all,
> >
> > It seems we've configured our branch protection rules such that pushing a
> > change to a PR that has been approved invalidates the previous approval.
> >
> > I think we should turn this off - it looks like it's an optional feature.
> > We should trust people to rerequest reviews if needed. Right now this is
> > adding busywork for people to reapprove minor changes (Fixing merge
> > conflicts, spotless, etc.)
> >
> > If you all agree I'll ask infra to uncheck "Dismiss stale pull request
> > approvals when new commits are pushed." in our branch protection rules.
> >
> > -Dan
>
>

Re: [DISCUSS] Tweak to branch protection rules

[Jinmei Liao]

+1

On Tue, Oct 29, 2019, 6:08 PM Owen Nichols  wrote:

> +1 …this has already bitten me a few times
>
> > On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> >
> > Hi all,
> >
> > It seems we've configured our branch protection rules such that pushing a
> > change to a PR that has been approved invalidates the previous approval.
> >
> > I think we should turn this off - it looks like it's an optional feature.
> > We should trust people to rerequest reviews if needed. Right now this is
> > adding busywork for people to reapprove minor changes (Fixing merge
> > conflicts, spotless, etc.)
> >
> > If you all agree I'll ask infra to uncheck "Dismiss stale pull request
> > approvals when new commits are pushed." in our branch protection rules.
> >
> > -Dan
>
>

Re: [DISCUSS] Tweak to branch protection rules

[Owen Nichols]

+1 …this has already bitten me a few times

> On Oct 29, 2019, at 6:01 PM, Dan Smith  wrote:
> 
> Hi all,
> 
> It seems we've configured our branch protection rules such that pushing a
> change to a PR that has been approved invalidates the previous approval.
> 
> I think we should turn this off - it looks like it's an optional feature.
> We should trust people to rerequest reviews if needed. Right now this is
> adding busywork for people to reapprove minor changes (Fixing merge
> conflicts, spotless, etc.)
> 
> If you all agree I'll ask infra to uncheck "Dismiss stale pull request
> approvals when new commits are pushed." in our branch protection rules.
> 
> -Dan

[DISCUSS] Tweak to branch protection rules

[Dan Smith]

Hi all,

It seems we've configured our branch protection rules such that pushing a
change to a PR that has been approved invalidates the previous approval.

I think we should turn this off - it looks like it's an optional feature.
We should trust people to rerequest reviews if needed. Right now this is
adding busywork for people to reapprove minor changes (Fixing merge
conflicts, spotless, etc.)

If you all agree I'll ask infra to uncheck "Dismiss stale pull request
approvals when new commits are pushed." in our branch protection rules.

-Dan

Re: Deprecate SystemFailure Class

[Bill Burcham]

The SystemFailure class is in the org.apache.geode package which means it
is part of the public API.

My purpose in messaging the dev list was to discover any concerns or
objections to adding the deprecated flag to SystemFailure per GEODE-7369.

Related to that work, I intend to eliminate calls to SystemFailure methods
e.g. initiateFailure() from within the membership subsystem per
https://issues.apache.org/jira/browse/GEODE-7354

It's my opinion we should eventually eliminate all such calls throughout
Geode eventually, but I don't know of any imminent plan to do so.

On Tue, Oct 29, 2019 at 8:26 AM Bruce Schuchardt 
wrote:

> Bill, are you proposing to remove calls to
> SystemFailure.initiateFailure() and remove all of the emergency-class
> stuff or just add a Deprecated flag to SystemFailure?
>
>
> On 10/28/19 12:01 PM, Bill Burcham wrote:
> > The SystemFailure class is a clearing house for detecting and attempting
> to
> > mitigate SystemFailure exceptions e.g. VirtualMachineError and
> > OutOfMemoryError.
> >
> > This class should not exist. SystemFailure exceptions should be allowed
> to
> > percolate up and cause the JVM to terminate as soon as possible with an
> > informative message in the log, if possible.
> >
> > Here is what the JVM spec has to say [1]:
> >
> > "A Java Virtual Machine implementation throws an object that is an
> instance
> > of a subclass of the class VirtualMethodError (sic) when an internal
> error
> > or resource limitation prevents it from implementing the semantics
> > described in this chapter. This specification cannot predict where
> internal
> > errors or resource limitations may be encountered and does not mandate
> > precisely when they can be reported."
> >
> > There's a typo in the spec there: it says "VirtualMethodError" when it
> > means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
> > apply after you've encountered a VirtualMachineError. As a result, there
> is
> > no reason to believe that subsequent processing will make things better
> > (than exiting immediately).
> >
> > The SystemFailure class should be deprecated so no new dependencies to it
> > are added. Existing dependencies on it, should be eliminated over time.
> >
> > Do you have any objections to deprecating the class and beginning
> > elimination of usage of it within Geode?
> >
> > Regards,
> > Bill
> >
> > [1]
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> > [2] oh and here's a ticket
> https://issues.apache.org/jira/browse/GEODE-7369
> >
>

Another Successful Apache Geode Summit - highlights and links to videos

[Jagdish Mirani]

Hello Apache Geode Community:
We wrapped up another great Geode Summit, with 12 content rich, well
organized and delivered, highly relevant Geode sessions at Geode Summit
2019. Thanks to everybody who made this event successful.

The Geode project, and the Geode Summit, have come a long way over the past
four years. Both, our downloads and Geode Summit attendance is trending
well. This year we drove record attendance with nearly 500 attendees at
Geode Summit. The community thrives when the community shares, and
several experts
from the Geode community shared their use cases, best practices, and
lessons learned.

Please promote this post

via
your networks - it covers highlights and videos from Geode Summit. If
you're interested in stats related to code commits, releases, merged pull
requests, jira ticket resolutions, and stats related to the event
attendees, then you'll find this intro presentation

useful.

I'm really encouraged by our trendline, and looking forward to another
record setting Geode Summit next year.

-- 
Regards
Jag

Re: The 1.11.0 branch we be cut on November 4th, 2019.

[Anthony Baker]

Heads up, I’m planning to merge a bunch of dependency updates today.

> On Oct 28, 2019, at 4:32 PM, Mark Hanson  wrote:
> 
> Please ensure that your changes are in November 3rd, 2019 at the latest. I 
> will pick the SHA of the first successful build on November 4th, 2019.
> 
> 
> If you realize your change will not make the cut and think it should, please 
> let me know.
> 
> 
> Thanks,
> Mark Hanson

Re: Deprecate SystemFailure Class

[Bruce Schuchardt]

Bill, are you proposing to remove calls to 
SystemFailure.initiateFailure() and remove all of the emergency-class 
stuff or just add a Deprecated flag to SystemFailure?



On 10/28/19 12:01 PM, Bill Burcham wrote:

The SystemFailure class is a clearing house for detecting and attempting to
mitigate SystemFailure exceptions e.g. VirtualMachineError and
OutOfMemoryError.

This class should not exist. SystemFailure exceptions should be allowed to
percolate up and cause the JVM to terminate as soon as possible with an
informative message in the log, if possible.

Here is what the JVM spec has to say [1]:

"A Java Virtual Machine implementation throws an object that is an instance
of a subclass of the class VirtualMethodError (sic) when an internal error
or resource limitation prevents it from implementing the semantics
described in this chapter. This specification cannot predict where internal
errors or resource limitations may be encountered and does not mandate
precisely when they can be reported."

There's a typo in the spec there: it says "VirtualMethodError" when it
means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
apply after you've encountered a VirtualMachineError. As a result, there is
no reason to believe that subsequent processing will make things better
(than exiting immediately).

The SystemFailure class should be deprecated so no new dependencies to it
are added. Existing dependencies on it, should be eliminated over time.

Do you have any objections to deprecating the class and beginning
elimination of usage of it within Geode?

Regards,
Bill

[1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
[2] oh and here's a ticket https://issues.apache.org/jira/browse/GEODE-7369

Re: Deprecate SystemFailure Class

[Joris Melchior]

+1.

On Mon, Oct 28, 2019 at 4:22 PM Robert Houghton 
wrote:

> +1.
>
> On Mon, Oct 28, 2019 at 12:11 PM Bill Burcham 
> wrote:
>
> > The SystemFailure class is a clearing house for detecting and attempting
> to
> > mitigate SystemFailure exceptions e.g. VirtualMachineError and
> > OutOfMemoryError.
> >
> > This class should not exist. SystemFailure exceptions should be allowed
> to
> > percolate up and cause the JVM to terminate as soon as possible with an
> > informative message in the log, if possible.
> >
> > Here is what the JVM spec has to say [1]:
> >
> > "A Java Virtual Machine implementation throws an object that is an
> instance
> > of a subclass of the class VirtualMethodError (sic) when an internal
> error
> > or resource limitation prevents it from implementing the semantics
> > described in this chapter. This specification cannot predict where
> internal
> > errors or resource limitations may be encountered and does not mandate
> > precisely when they can be reported."
> >
> > There's a typo in the spec there: it says "VirtualMethodError" when it
> > means "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not
> > apply after you've encountered a VirtualMachineError. As a result, there
> is
> > no reason to believe that subsequent processing will make things better
> > (than exiting immediately).
> >
> > The SystemFailure class should be deprecated so no new dependencies to it
> > are added. Existing dependencies on it, should be eliminated over time.
> >
> > Do you have any objections to deprecating the class and beginning
> > elimination of usage of it within Geode?
> >
> > Regards,
> > Bill
> >
> > [1]
> > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> > [2] oh and here's a ticket
> > https://issues.apache.org/jira/browse/GEODE-7369
> >
>


-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*

Special certificates for multisite

[Mario Ivanac]

Hi,

We are trying to find a solution for an situation we have. Below is the 
explanation of the issue, as well as a proposed way forward. We would 
appreciate comments from the community regarding this approach. Also, 
suggestions for a different approach to solve this issue would be welcome.

The situation is the following: when SSL is enabled, we would like to use 
multiple certificates in locators and servers: one certificate for 
communication inside one geographical site, and another for the communication 
happening between geographical sites. The approach we took is to use the 
default SSL context and implement our own Java Security Provider.

The client side can, from the security provider, easily distinguish which 
certificate to use (just check if you are initiating a connection towards an IP 
listed in gemfire.remote-locators). The thing we are missing is a criteria 
based on which we can choose the certificate on the server side of the 
connection. Explanation: Once the handshake starts, a ClientHello message is 
sent from the peer acting as a client in that connection (be it a geode server 
or a geode locator). When the ClientHello is received on the server side, we 
can’t always read the real originating IP (keeping the originating IP is 
sometimes not possible in cloud native environments), so we can’t be sure 
whether the message originated from the same geographical site or from another. 
We are left only with the information inside the ClientHello message. The 
default ClientHello message doesn’t contain information based on which we can 
conclude which site the message came from and which certificate to use.

Our proposal is to add the server_name extension in the ClientHello message. 
The content of that extension would be the distributed system ID of the site 
where the ClientHello originated. This way we could compare the distributed 
system ID in the ClientHello message with the ID of the site where the message 
is received.

One issue with this approach is that the usage of the extension wouldn’t be 
completely in line with the RFC 
description: we would be inserting client information instead of the targeted 
server name. Still, since this extension is otherwise of no use in Geode, and 
this approach doesn’t present a security risk (we would be sharing the 
distributed system ID, which doesn’t look dangerous), we see this as a 
potential way to go.