RE: WAN replication issue in cloud native environments

[Alberto Bustamante Reyes]

Thanks Charlie, but the issue is not about connectivity. Summarizing the issue, 
the problem is that if you have two or more gw receivers that are started with 
the same value of "hostname-for-senders", "start-port" and "end-port" (being 
"start-port" and "end-port" equal) parameters, if one gw receiver stops, the 
locator will publish to any remote locator that there are no receivers up.

And this use case is likely to happen on cloud-native environments, as 
described.

BR/

Alberto B.

De: Charlie Black 
Enviado: miércoles, 4 de diciembre de 2019 18:11
Para: dev@geode.apache.org 
Asunto: Re: WAN replication issue in cloud native environments

Alberto,

Something else to think about SNI based routing.   I believe Mario might be
working on adding SNI to Geode - he at least had a proposal that he
e-mailed out.

Basics are the destination host is in the SNI field and the proxy can
inspect and route the request to the right service instance. Plus we
have the option to not terminate the SSL at the proxy.

Full disclosure - I haven't tried out SNI based routing myself and it is
something that I thought could work as I was reading about it.   From the
whiteboard I have done I think this will do ingress and egress just fine.
Potentially easier then port mapping and `hostname for clients` playing
around.

Just something to think about.

Charlie


On Wed, Dec 4, 2019 at 3:19 AM Alberto Bustamante Reyes
 wrote:

> Hi Jacob,
>
> Yes,we are using LoadBalancer service type. But note the problem is not
> the transport layer but on Geode as GW senders are complaining
> “sender-2-parallel : Could not connect due to: There are no active
> servers.” when one of the servers in the receiving cluster is killed.
>
> So, there is still one server alive in the receiving cluster but GW sender
> does not know it and the locator is not able to inform about its existence.
> Looking at the code it seems internal data structures (maps) holding the
> profiles use object whose equality check relies only on hostname and port.
> This makes it impossible to differentiate servers when the same
> “hostname-for-senders” and port are used. When the killed server comes back
> up, the locator profiles are updated (internal map back to size()=1
> although 2+ servers are there) and GW senders happily reconnect.
>
> The solution with the Geode as-is would be to expose each GW receiver on a
> different port outside of k8s cluster, this includes creating N Kubernetes
> services for N GW receivers in addition to updating the service mesh
> configuration (if it is used, firewalls etc…). Declarative nature of
> kubernetes means we must know the ports in advance hence start-port and
> end-port when creating each GW receiver must be equal and we should have
> some well-known
> algorithm when creating GW receivers across servers. For example: server-0
> port 5000, server-1 port 5001, server-2 port 5002 etc…. So, all GW
> receivers must be wired individually and we must turn off Geode’s random
> port allocation.
>
> But we are exploring the possibility for Geode to handle this cloud-native
> configuration a bit better. Locators should be capable of holding GW
> receiver information although they are hidden behind same hostname and port.
> This is a code change in Geode and we would like to have community opinion
> on it.
>
> Some obvious impacts with the legacy behavior would be when locator picks
> a server on behalf of the client (GW sender in this case) it does so based
>  on the server load. When sender connects and considering all servers are
> using same VIP:PORT it is load balancer that will decide where the
> connection will end up, but likely not on the one selected by locator. So
> here we ignore the locator instructions. Since GW senders normally do not
> create huge number of connections this probably shall not unbalance cluster
> too much. But this is an impact worth considering. Custom load metrics
> would also be ignored by GW senders. Opinions?
>
> Additional impact that comes to mind is GW sender load-balance command and
> how it’s execution would be affected.
>
> Thanks!
>
> Alberto B.
>
> 
> De: Jacob Barrett 
> Enviado: viernes, 29 de noviembre de 2019 13:06
> Para: dev@geode.apache.org 
> Asunto: Re: WAN replication issue in cloud native environments
>
>
>
> > On Nov 29, 2019, at 3:14 AM, Alberto Bustamante Reyes
>  wrote:
> >
> > The reason for such a setup is deploying Geode cluster on a Kubernetes
> cluster where all GW receivers are reachable from the outside world on the
> same VIP and port.
>
> Are you using LoadBalancer Service type?
>
> > Other kinds of configuration (different hostname and/or different port
> for each GW receiver) are not cheap from OAM and resources perspective in
> cloud native environments and also limit some important use-cases (like
> scaling).
>
> If you could somehow configure host and port for sender (code modification
> required) would

Importance of Diffie-Hellman support in native client?

[Blake Bender]

Please see https://issues.apache.org/jira/browse/GEODE-7302.  We have a
ticket to make a decision about whether or not to deprecate a couple of
properties here, and any knowledge of them has long since left the team.
Does anyone have a clue, or informed opinion, as to the importance of
keeping this support and the associated properties?

Thanks,

Blake

Re: Importance of Diffie-Hellman support in native client?

[Charlie Black]

Diffie-Hellman is a valid and in-use protocol by the larger security
community.

On Thu, Dec 5, 2019 at 8:24 AM Blake Bender  wrote:

> Please see https://issues.apache.org/jira/browse/GEODE-7302.  We have a
> ticket to make a decision about whether or not to deprecate a couple of
> properties here, and any knowledge of them has long since left the team.
> Does anyone have a clue, or informed opinion, as to the importance of
> keeping this support and the associated properties?
>
> Thanks,
>
> Blake
>


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

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Dan Smith]

+1 to what Jake said.

-Dan

On Wed, Dec 4, 2019 at 11:32 PM Owen Nichols  wrote:

> +1 for a short-term solution in 1.11 while we discuss a more complete
> proposal for 1.12
>
> On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett  wrote:
>
> > I think we can tone down the inflammatory statements. It is well
> > established that, like any legacy code base, Geode has issues. One of
> them
> > is a less than ideal set of APIs for certain tasks. Whatever the issues
> > were in the past with getting APIs adjusted to suit the SDG project
> should
> > be left in the past and we can work forward on a new strategy.
> >
> > The term public API is redundant, if its designated API then it is
> public.
> > Let’s also be clear that "internal API” is not a thing, if it is internal
> > it is not an API. The language semantics of public/private are not what
> > defines and API. As such, relying on internal classes tor work around
> > deficiencies in a API is dangerous and should only be done as a stopgap
> > measure while addressing the API’s deficiency. Java, up until 9, lacked
> any
> > clear distinction of internals vs API so, like many projects, Geode chose
> > the “internal” package name to denote things that are not to be consume
> as
> > API. As we go forward with Java 9 modules support these will be enforced
> by
> > the runtime and compilers.
> >
> > A JIRA should be opened to address the API deficiency. When the API is
> > enhanced then the internal class usage should be replaced immediately
> with
> > the API. It is unreasonable to expect an upstream project to maintain
> > internal classes as though they are API or expect them to address
> > deficiencies in the API if they are not communicated. It is also
> > unreasonable for the upstream project to ignore obvious deficiencies in
> its
> > APIs and should use these issues raised by downstream projects to
> > prioritize improvements. Work needs to be done on both these projects to
> > make improvements.
> >
> > To resolve the issues raised below let’s get some JIRAs and/or RFCs
> opened
> > to address the APIs the SDG needs to work. Let’s work to burn down this
> > debt of internal class usage in SDG to avoid issues like this in the
> > future. I am sure we can figure out a short term solution to address the
> > immediate compile issues, whether that’s making a unit test into an
> > integration test, refactoring the internals to not blindly cast, or
> > whatever. We can then work out a strategy to address this the correct way
> > in the develop branch for 1.12.
> >
> > -Jake
> >
> >
> >
> > > On Dec 4, 2019, at 6:20 PM, John Blum  wrote:
> > >
> > > If you must know, there are important test cases in both SBDG and SSDG
> to
> > > be able to register (and subsequently unregister) the "mock" Pool with
> > the
> > > PoolManager, which unfortunately is a consequence of the SDG
> > > PoolFactoryBean's design being reliant on the PoolManager (to resolve
> the
> > > Pool), and to some extent, the PoolFactory API (to create the Pool)  in
> > the
> > > first place.  Of course, there is no other way to "resolve" a reference
> > to
> > > a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
> > >
> > > Unfortunately, STDG (or SDG) would not need to import "internal" APIs
> if
> > > Apache Geode's public API was properly maintained and evolved to
> address
> > a
> > > new use cases.  For example (and again), see GEODE-7532
> > >  [1].
> > >
> > > It turns out, there are many, many cases like GEODE-7532
> > >  [1], with classes
> and
> > > methods containing useful functions buried deep down inside Geode
> > > "internal" packages.  The o.a.g.distributed.internal.MemberListener
> > > interface comes to mind.  It is not difficult to see how his interface
> > > would be useful in both frameworks & tooling (e.g. for management &
> > > monitoring).
> > >
> > > Or, how about the poor resource management/cleanup Apache Geode fails
> to
> > do
> > > properly w.r.t. SSL Sockets, that STDG now needs to account for
> > > <
> >
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> > >
> > > [2]
> > > when running automated integration tests.
> > >
> > > I think there was another example
> > >  [3] recently, which
> STDG
> > > must account for  [4]
> as
> > > well.
> > >
> > > Serializer registration/unregistration is yet another area.  The
> laundry
> > > list is quite long!
> > >
> > > The whole notion of Apache Geode's "internal" API is horribly broken,
> > > especially when the public API often comes up short.
> > >
> > > What troubles me is that we see the recommended changes in GEODE-7532
> as
> > a
> > > "bandaid".  Really?
> > >
> > > It

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Owen Nichols]

> On Dec 4, 2019, at 10:09 PM, Jacob Barrett  wrote:
> 
> I think we can tone down the inflammatory statements

Jake, thank you for speaking up, I felt the same way but wasn’t sure how to say 
it.

This might be a good opportunity for all of us to review the 
https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Anilkumar Gingade]

Trying to get a conclusion out of it:
- The SDG/STDG to address the issue by changing the code on its part
- Create JIRA ticket for the issue raised. And prioritize/work the issue in
coming GEODE release.

-Anil.


On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols  wrote:

> > On Dec 4, 2019, at 10:09 PM, Jacob Barrett  wrote:
> >
> > I think we can tone down the inflammatory statements
>
> Jake, thank you for speaking up, I felt the same way but wasn’t sure how
> to say it.
>
> This might be a good opportunity for all of us to review the
> https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct

[DISCUSS] Replacing singleton PoolManager

[Dan Smith]

Hi,

I wrote up a proposal for deprecating of the singleton PoolManager in favor
of a ClientCache scoped service. Please review and comment on the below
proposal.

I think this should address the issues that Spring Data Geode and friends
had trying to mock Pools and remove the need for those projects to try to
inject mock Pools into a Geode singleton.

https://cwiki.apache.org/confluence/display/GEODE/Replace+singleton+PoolManager+with+ClientCache+scoped+service

Thanks,
-Dan

Re: [DISCUSS] Replacing singleton PoolManager

[Dale Emery]

+1

To the extent possible without breaking existing APIs, please name the new 
stuff to indicate what’s in the pool (E.g. ConnectionPool, 
ConnectionPoolService, and so on).

—
Dale Emery
dem...@pivotal.io



> On Dec 5, 2019, at 4:40 PM, Dan Smith  wrote:
> 
> Hi,
> 
> I wrote up a proposal for deprecating of the singleton PoolManager in favor
> of a ClientCache scoped service. Please review and comment on the below
> proposal.
> 
> I think this should address the issues that Spring Data Geode and friends
> had trying to mock Pools and remove the need for those projects to try to
> inject mock Pools into a Geode singleton.
> 
> https://cwiki.apache.org/confluence/display/GEODE/Replace+singleton+PoolManager+with+ClientCache+scoped+service
> 
> Thanks,
> -Dan

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Dan Smith]

I had a side conversation with John. I created a proposal in a separate and
a JIRA (GEODE-7555) for what I think is a good long term solution to the
issues STDG had mocking the Geode API.

In the short term, I'm fine with whatever we decide we should do to support
STDG.

-Dan

On Thu, Dec 5, 2019 at 11:36 AM Anilkumar Gingade 
wrote:

> Trying to get a conclusion out of it:
> - The SDG/STDG to address the issue by changing the code on its part
> - Create JIRA ticket for the issue raised. And prioritize/work the issue in
> coming GEODE release.
>
> -Anil.
>
>
> On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols  wrote:
>
> > > On Dec 4, 2019, at 10:09 PM, Jacob Barrett 
> wrote:
> > >
> > > I think we can tone down the inflammatory statements
> >
> > Jake, thank you for speaking up, I felt the same way but wasn’t sure how
> > to say it.
> >
> > This might be a good opportunity for all of us to review the
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct
>