Re: spotlessGroovyGradleCheck failures in clean checkout on windows

[Jens Deppe]

Hi Kirk.

Does running with ‘—info’ give some more insight?

--Jens

From: Kirk Lund 
Date: Thursday, May 11, 2023 at 5:21 PM
To: dev@geode.apache.org 
Subject: spotlessGroovyGradleCheck failures in clean checkout on windows
!! External Email

Anyone know why a fresh checkout of develop has all of the following
failures on Windows?

> ./gradlew clean
> ./gradlew build -x test

> Task :geode-cq:spotlessGroovyGradleCheck FAILED
> Task :geode-server-all:spotlessGroovyGradleCheck FAILED
> Task :geode-membership:spotlessGroovyGradleCheck FAILED
> Task :geode-assembly:geode-assembly-test:spotlessGroovyGradleCheck FAILED
> Task :extensions:geode-modules:spotlessGroovyGradleCheck FAILED


> Task :geode-logging:spotlessGroovyGradleCheck FAILED
> Task :extensions:geode-modules-test:spotlessGroovyGradleCheck FAILED
> Task :geode-tcp-server:spotlessGroovyGradleCheck FAILED
> Task :geode-connectors:spotlessGroovyGradleCheck FAILED
> Task :geode-management:spotlessGroovyGradleCheck FAILED
> Task :geode-rebalancer:spotlessGroovyGradleCheck FAILED


> Task :geode-lucene:spotlessGroovyGradleCheck FAILED
> Task :geode-unsafe:spotlessGroovyGradleCheck FAILED
> Task :geode-serialization:spotlessGroovyGradleCheck FAILED
> Task :extensions:session-testing-war:spotlessGroovyGradleCheck FAILED
> Task :geode-common:spotlessGroovyGradleCheck FAILED
> Task :geode-dunit:spotlessGroovyGradleCheck FAILED


> Task :geode-gfsh:spotlessGroovyGradleCheck FAILED
> Task :geode-junit:spotlessGroovyGradleCheck FAILED


> Task :geode-web-management:spotlessGroovyGradleCheck FAILED
> Task :geode-log4j:spotlessGroovyGradleCheck FAILED
> Task :geode-pulse:spotlessGroovyGradleCheck FAILED
> Task :geode-core:spotlessGroovyGradleCheck FAILED
> Task :geode-assembly:spotlessGroovyGradleCheck FAILED


> Task :geode-http-service:spotlessGroovyGradleCheck FAILED


> Task :geode-deployment:geode-deployment-legacy:spotlessGroovyGradleCheck
FAILED

> Task :geode-old-client-support:spotlessGroovyGradleCheck FAILED


> Task :geode-memcached:spotlessGroovyGradleCheck FAILED
> Task :extensions:geode-modules-session-internal:spotlessGroovyGradleCheck
FAILED

> Task :geode-wan:spotlessGroovyGradleCheck FAILED
> Task :extensions:geode-modules-session:spotlessGroovyGradleCheck FAILED


> Task :extensions:geode-modules-tomcat7:spotlessGroovyGradleCheck FAILED


> Task :extensions:geode-modules-tomcat8:spotlessGroovyGradleCheck FAILED


> Task :extensions:geode-modules-tomcat9:spotlessGroovyGradleCheck FAILED


> Task :geode-concurrency-test:spotlessGroovyGradleCheck FAILED


> Task :geode-web-api:spotlessGroovyGradleCheck FAILED
> Task :geode-lucene:geode-lucene-test:spotlessGroovyGradleCheck FAILED


> Task :geode-jmh:spotlessGroovyGradleCheck FAILED
> Task :static-analysis:spotlessGroovyGradleCheck FAILED


> Task :geode-pulse:geode-pulse-test:spotlessGroovyGradleCheck FAILED



> Task :boms:geode-client-bom:spotlessGroovyGradle
Errors occurred while build effective model from
C:\Users\kirkl\.gradle\caches\modules-2\files-2.1\org.eclipse.platform\org.eclipse.core.expressions\3.8.200\eb159f34083b0135459745f934a6ad5eb61b61c\org.eclipse.core.expressions-3.8.200.pom:


'modelVersion' must be one of [4.0.0] but is '4.0'. in
org.eclipse.platform:org.eclipse.core.expressions:3.8.200

Errors occurred while build effective model from
C:\Users\kirkl\.gradle\caches\modules-2\files-2.1\org.eclipse.platform\org.eclipse.core.filesystem\1.9.500\a170901fc0ef24de65515b0a96dc02fb6175\org.eclipse.core.filesystem-1.9.500.pom:
'modelVersion' must be one of [4.0.0] but is '4.0'. in
org.eclipse.platform:org.eclipse.core.filesystem:1.9.500

Errors occurred while build effective model from
C:\Users\kirkl\.gradle\caches\modules-2\files-2.1\org.eclipse.platform\org.eclipse.swt\3.123.0\9e43f16c2ff40b4e45195d447e9f764853356158\org.eclipse.swt-3.123.0.pom:
'dependencies.dependency.artifactId' for
org.eclipse.platform:org.eclipse.swt.${osgi.platform}:jar with value
'org.eclipse.swt.${osgi.platform}' does not match a valid id pattern. in
org.eclipse.platform:org.eclipse.swt:3.123.0



> Task :boms:geode-client-bom:spotlessGroovyGradleCheck FAILED


> Task :extensions:geode-modules-assembly:spotlessGroovyGradleCheck FAILED


> Task :static-analysis:pmd-rules:spotlessGroovyGradleCheck FAILED


> Task :geode-web:spotlessGroovyGradleCheck FAILED

!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.

Re: [PROPOSAL] annul support/1.15

[Jens Deppe]

+1

From: Owen Nichols 
Date: Wednesday, March 16, 2022 at 2:12 PM
To: geode 
Subject: [PROPOSAL] annul support/1.15
Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 a 
few weeks ago.  I wonder if perhaps we cut the release branch prematurely?  I 
propose that we abandon this branch and focus on getting develop closer to what 
we want to ship, then discuss re-cutting the branch.

If this proposal is approved, I will archive support/1.15 as support/1.15.old, 
revert develop's numbering to 1.15.0, and bulk-update all Jira tickets fixed in 
1.16.0 to fixed in 1.15.0 instead.  Build numbering would start from 
1.15.0-build.1000 to easily distinguish pre- and post- recut.

Please vote/discuss with a goal of reaching consensus by 3PM PDT Monday Mar 21.

Thanks,
-Geode 1.15.0 Release Manager

PR to add unique ID to DUnit log output

[Jens Deppe]

Hi All.

Just a heads up that I have a PR up (https://github.com/apache/geode/pull/7232) 
which, if merged, will slightly change the log output from DUnit runs. The PR 
simply adds a 4 character unique ID to the log line. As in:

[vm0-51ec] [info 2021/12/24 15:43:54.367 UTC  ; tid=0x1d] Reinitializing JarDeploymentService with 
new working directory: null

[vm0-47b7] [info 2021/12/24 15:43:54.416 UTC   tid=0x1d] Reinitializing JarDeploymentService with 
new working directory: null

[vm1-47b7] [info 2021/12/24 15:43:54.431 UTC   tid=0x1d] Received method: 
org.apache.geode.test.dunit.internal.IdentifiableCallable.call with 0 args on 
object: IdentifiableCallable(0:start locator in vm0)

The ID is intended to be unique per test run when tests are run repeatedly.

I did this to assist in debugging test output from repeated test runs 
(StressNewTest) where individual tests’ log lines are simply interleaved making 
debugging very difficult.

The change, unfortunately, does not affect log lines generated from the test VM 
but only from VMs launched by the ProcessManager. If anyone has ideas how to do 
that, I’d love to hear them.

Well, actually one approach I’ve used is related to this PR 
(https://github.com/apache/geode/pull/7231) which lets one name 
ExecutorServiceRule threads. Using this, I can use the ProcessManager.ID to 
name the executor threads and thus that ID becomes visible when the thread name 
is logged. Kinda hacky, but it’s still effective.

Anyway, this is not a call to review (although you’re welcome to do so) but 
just a FYI.

--Jens

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.6.RC2

[Jens Deppe]

+1

Used gfsh to create a SSL-enabled cluster; ran various gfsh commands.

--Jens


From: Owen Nichols 
Date: Friday, December 10, 2021 at 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.6.RC2
Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.6.RC2.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.12.6.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.6data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fY4UNnU006ZqV3z4F8jtpRgPFuH4DdxSg6QN9n%2Bd4Zg%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.6.RC2%2Fdata=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BHSU79qMRz1PDPuUjE8RimFn3IWQAU%2Fr8Ae7sFIESEk%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1119data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OdBm7UQgqSUL0kr8Cy7HxV7EMYshz6%2F8cthmTfGeg68%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IGh8M%2FG72Cy217HYUFsRaVY16FIh4h%2F03O1dKZU%2BNUQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NZGhXYxN6NxAPWsLdN6awdXx6Z0dACY5fv0%2BoUdP3Kk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=jl32CUFvXik8IM0RN421tP2v1JsLfriiw%2BtayQmh%2B14%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.6.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7BL1qhBEbiDjX%2BkydQ7pQMwqIlxYAhj%2BftLG21Jrw20%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=no1WSy4BAIAcg6Xtnl6fIzuAi7aq6qwkMq4U%2F4SdLrc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cjdeppe%40vmware.com%7Cbf82dc4d1f8e47c2748908d9bc29b183%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709522507342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=m9gzFaOpK1kK%2F0cxnGOEFCE7KYCwx0Rs3a5SffRJ9PY%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

Re: [Suspected Spam] [VOTE] Apache Geode 1.14.1.RC2

[Jens Deppe]

+1

Used gfsh to create a SSL-enabled cluster; ran various gfsh commands.

--Jens


From: Owen Nichols 
Date: Friday, December 10, 2021 at 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.1.RC2
Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.1.RC2.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.14.1.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.1data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uOPWEdFpvTmi8r5uyBNmdgrLZUr5nHEZtRpP1VN%2Fa6U%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.1.RC2%2Fdata=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6QO6yP6yFwR8vx9ecaNECA2Hw%2BQOSc3UMBL2OpRSQw4%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1118data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=HsJR%2BDSEzzK9fvZTek47b4iB%2BqG7tm7AScwvuLmdas0%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DEs7w2kMk3Eg%2F84E7N%2Bqkf4sL%2B%2FAibVudkh%2F1n72I4o%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ni34jBrkApQUIMps%2FgJYW5uVVcD8EhJyHaKca3212dw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2F4PLlD8fMX4qNAb0Zm7OWbRDjNA25vOpBEQle2fw6Tk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.1.RC2data=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=jIyevAXj2mBlNuJnsXYawQc1ktJIaU0U57gdtgr4Ctk%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=thWhFF%2B6bPbePI1ybCwVWi7T16iw0oYKAYMCGd%2BwZLI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cjdeppe%40vmware.com%7C33e07c93e5734998998d08d9bc29b721%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709619685452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=B7nnm77fW%2BUoC2OFQhaPb7Rwz%2FX8oud0eflx69a%2FBog%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.5.RC2

[Jens Deppe]

+1

Used gfsh to create a SSL-enabled cluster; ran various gfsh commands.

--Jens

From: Owen Nichols 
Date: Friday, December 10, 2021 at 2:09 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.5.RC2
Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.5.RC2.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

EXPEDITED Voting deadline:
3PM PST Sat, December 11 2021.

Please note that we are voting upon the source tag:
rel/v1.13.5.RC2

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.5data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547036219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KhGNLvomGlD1HQo%2FOTDrXEIJsn831qnRUv2W3iriB6Y%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.5.RC2%2Fdata=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547036219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=z%2FoaDy5TNjqTjMjyTv%2FDziMAQ5Z15wPvq%2Fc1G4ob5%2FA%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1117data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547036219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=JxRnwmQbWLEljfeKp0NwbO%2Bpy5w5HS8mB1gUSqwF0Co%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547036219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ukwju9L5t0UK2REx6upnGCHE91o11Qplxtrl9kzSSY0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547036219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LuGFoxXeNane%2BwwgUwwSwil83GFCwtfurfq6QNXjHVg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547192457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=wLtG8S0GwoFEYoy%2F%2BpPj1yAVdUFkCOOLOawMtcT7C0Q%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.5.RC2data=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547192457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6BwEw%2FnJ88hULSr3jqEMRx7AVAASzjH1XsG8B3zHC7s%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547192457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KVjxevlkeK1A%2FQ0I7znrbjdtYnwKRiqW6utEWvS82Bo%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Cjdeppe%40vmware.com%7Cfcf0fa78cb9c4aa1b53208d9bc29b205%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637747709547192457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Lq9U3lFSfVybP35AoyniwltEct%2FCekYt7xSU7YKmKGg%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

[PROPOSAL]: RFC to introduce a service provider interface for Data Serializable Fixed IDs

[Jens Deppe]

Hello fellow devs!

I would appreciate your time and review for the stated RFC.

https://cwiki.apache.org/confluence/display/GEODE/Service+Loader+interface+for+Data+Serializable+Fixed+IDs

The review period is until Friday, October 8.

Thank you!
--Jens

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Jens Deppe]

Would it be possible to allow an operator to choose which version of Lucene to 
use? Such that if they are prepared for the issues you describe, they could 
still go ahead and upgrade to 7.10. Or are there breaking API changes which 
would make that hard/impossible to accommodate in our code base?

--Jens

From: nabarun nag 
Date: Monday, September 27, 2021 at 11:49 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Upgrading to Lucene 7.1.0
Hi dev team,

Recently, a commit was pushed to develop which upgraded the Lucene
version used in Apache Geode to 7.1.0. These new Lucene indexes are
not compatible with the previous versions hence it breaks the rolling
upgrade contract. We are no longer able to execute Lucene queries when
there are severs of mixed versions in the cluster. One solution that
was provided was to not allow Lucene queries to be executed when there
are mixed versions of servers present in the cluster.

After a discussion, it was put forward that this was not an optimal
user experience. Also, that this change of default behavior was not
discussed in the dev list.

Alternative solutions that were put forward were that Geode allowed
the user to pick the version of Lucene to be used. Another that since
this is a major upgrade to Lucene with some breaking API changes,
should we sync this upgrade with the release of Apache Geode 2.0

We would love to hear your thoughts or alternative solutions to this issue.

Regards
Nabarun.

Re: [VOTE] Apache Geode 1.12.4.RC1

[Jens Deppe]

+1

Built from source bundle
Startup using SSL properties
Perform various basic gfsh operations.

--Jens

From: Dick Cavender 
Date: Wednesday, July 21, 2021 at 4:35 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.12.4.RC1
Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.4.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you
performed.

Voting deadline:
*3PM PST Mon, July 26 2021*

Please note that we are voting upon the source tag:
rel/v1.12.4.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.4data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281871641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cQAf5r7QlE9JSijQXtIb95B2RD0H9TQ%2B7MgsSw%2BPQ5I%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.4.RC1%2Fdata=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281871641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pr7Fzli%2B9SXpO9RmfooChe9GhJrNKcuigrTgQ8SLlpM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1092data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281871641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qA1RUbfk7RYaZYDmDaj%2FsoioAUu0YklvswIZga8k4W4%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281871641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=78oN5koUK9akhyPxw2yoCws9%2FVFCZqFHR0yV9hWb2Mw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281881639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mEs9H3Ej10GUv6p6i5s1%2Be39l2enUq35%2BSXjGBespIE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281881639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=N%2BTcaibKLMCSf1fn6WaOEGs7cGH8A806bLp4kotCDHQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281881639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bZZxX8z%2Fz%2FDQOy3Z4dJ%2FPRZ6QQcn70pGi%2FKL%2BSKqYk0%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281881639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bm0git2gqsEuU2wE4XVIaVc5FCdd11ohoaYPTahWV%2BI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cjdeppe%40vmware.com%7Ceab88044acba48e1ef0608d94ca036a8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637625073281881639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hKf3tXz44LUzWGbrU044uHqmx7DDRToGMNw8WeqIMwg%3Dreserved=0

Geode's KEYS file containing PGP keys we use to sign the release:

Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Jens Deppe]

+1 For Naba’s proposal

From: Joris Melchior 
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.

From: Nabarun Nag 
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols , dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can’t find any example of an intentional merge 
commit on develop…but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don’t like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” 
rather than “Squash and Merge”.

While the community consensus was to continue to allow all merge options, 
please try to default to “Squash and Merge” whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it’s easy to miss when it resets itself back to the 
default of “Merge” some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

Re: [Discuss] New feature work approval state in Geode project?

[Jens Deppe]

Oh, I see now. Yes, +1 to what Jake said.

From: Jacob Barrett 
Date: Friday, May 28, 2021 at 10:41 AM
To: dev@geode.apache.org 
Subject: Re: [Discuss] New feature work approval state in Geode project?
Can you provide a more concrete example? I don’t understand why there would be 
a JIRA written without a reasonable belief it would be executed on. A JIRA that 
is later determined to not be worth the effort, not a bug, or whatever, should 
just closed as “won’t fix”.

> On May 28, 2021, at 10:36 AM, Mark Hanson  wrote:
>
> Hi All,
>
> There has been some discussion about adding a new state of approved to Geode 
> Jira for features or something like it, to help prevent work being done that 
> doesn’t make it into the project. What to people think?
>
> Thanks,
> Mark

Re: [Discuss] New feature work approval state in Geode project?

[Jens Deppe]

Hi Mark,

Could you explain that a bit more – I’m not clear what you mean by: “to help 
prevent work being done that doesn’t make it into the project”.

Does that mean work that isn’t somehow related to a (new) feature.

--Jens

From: Mark Hanson 
Date: Friday, May 28, 2021 at 10:36 AM
To: dev@geode.apache.org 
Subject: [Discuss] New feature work approval state in Geode project?
Hi All,

There has been some discussion about adding a new state of approved to Geode 
Jira for features or something like it, to help prevent work being done that 
doesn’t make it into the project. What to people think?

Thanks,
Mark

Re: Reminder to use draft mode

[Jens Deppe]

To be clear. I’m absolutely in favor of using draft mode as an initial 
indicator of the state of a PR.

What I’m not in favor of is requiring the PR to be switched back and forth. 
Certainly, if any individual developer wants to do that, of course that’s their 
prerogative.

--Jens.

From: Mark Hanson 
Date: Thursday, May 6, 2021 at 10:45 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode
I agree, I like the draft mode switch. The hesitations that I have are 
mentioned by Jens in that you can have failures that are unrelated. Especially 
DUnits at this point. Perhaps for required tests following the draft mode 
approach is better. I have had many cases where I see PRs that obviously need 
work asking for my review and I have to look past them in my review requested 
PR list. There have been several PRs that have been untouched for months that 
were failing tests but my review was required...

+1 for draft mode as the best approach to get to passing tests, then normal 
mode once the PR is ready. (not that we are voting)

Thanks,
Mark

On 5/6/21, 10:22 AM, "Nabarun Nag"  wrote:

I feel that Owen has a valid point and I myself feel that it is ok to start 
the PR in draft mode till the pre-check tests pass.

There has been this situation where,

  *   PR is created (reviewers are assigned)
  *   approved
  *   Tests fail
  *   code is changed
  *   no reviews
  *   code is merged

Hence code that is not reviewed has been merged

This way of doing work also has the following advantages:

  *   A reviewer does not have to review a code that causes tests to fail
  *   A reviewer does not have to review code twice before failure and then 
again after changing the code to fix the failure
  *   Unreviewed code post-test fixes do not get merged

I think this way of working saves a critical amount of time for engineers 
who review code.

This flow of PRs feels more efficient:


  *   Create PR in draft mode - no reviewers assigned
  *   PRechecks fail
  *   change/fix code
  *   tests pass - all green
  *   convert PR to ready for review - reviewers assigned
  *   reviewers review

Regards
Naba




From: Owen Nichols 
Sent: Thursday, May 6, 2021 9:59 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

Given the lack of consensus, it sounds like it will not be possible to make 
any assumptions about a PR based on whether it is in Draft mode or not.  I will 
stop retriggering flaky checks or changing PRs to draft status.  My apologies 
for the inconvenience this has caused.

On 5/6/21, 9:47 AM, "Jens Deppe"  wrote:

I don’t think we can presume everyone has the same working style. For 
myself I’ll happily review a PR that has a failing check. I’m OK if it has some 
innocuous ‘housekeeping’ error or unrelated failure.

I don’t retrigger PR failures, for unrelated errors, just to ‘get to 
green’ – related, I don’t expect anyone to do that on my part either. It would 
be frustrating if I was about to merge something and someone retriggers a job. 
Yes I do merge if I’m 100% confident the failed check is unrelated. I don’t 
merge if any checks are still pending.

Perhaps this is just relevant to my current situation, but most of my 
PRs are module specific and so there is collaboration between my team and we 
typically know the state of our various PRs. I don’t feel like there is much 
need for any process around switching in and out of Draft mode. Much less for 
an ‘external’ contributor to make decisions on our behalf.

Has some situation arisen that is driving this? It feels like there is 
some underlying issue that isn’t being fully communicated.

--Jens

From: Owen Nichols 
Date: Thursday, May 6, 2021 at 9:12 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode
A PR in "Draft" mode simply conveys that at least one more commit is 
coming before it will be "done".  Reviewers generously volunteer their time to 
look at your PR, and are welcome to look at it while in draft mode if they 
wish, but if they are quite busy, some may prefer to wait until the PR is 
plausibly code-complete before setting aside time to review it.

Sorry if I wasn't clear, I don't mean that flaky failures should mean a 
PR is not done.  You can always refer to the latest mass test report for a list 
of known flaky failures, but often I will see those and retrigger them for you 
anyway.

I expect that most PR submitters will be monitoring their own PR checks 
and taking it back to draft mode as soon as they realize more changes are 
needed.  But if as a community we agree to use draft mode to communicate status 
in this way, it shouldn't matter who does it.

Due to CODEOWNERS, some reviewers have a huge

Re: Reminder to use draft mode

[Jens Deppe]

I don’t think we can presume everyone has the same working style. For myself 
I’ll happily review a PR that has a failing check. I’m OK if it has some 
innocuous ‘housekeeping’ error or unrelated failure.

I don’t retrigger PR failures, for unrelated errors, just to ‘get to green’ – 
related, I don’t expect anyone to do that on my part either. It would be 
frustrating if I was about to merge something and someone retriggers a job. Yes 
I do merge if I’m 100% confident the failed check is unrelated. I don’t merge 
if any checks are still pending.

Perhaps this is just relevant to my current situation, but most of my PRs are 
module specific and so there is collaboration between my team and we typically 
know the state of our various PRs. I don’t feel like there is much need for any 
process around switching in and out of Draft mode. Much less for an ‘external’ 
contributor to make decisions on our behalf.

Has some situation arisen that is driving this? It feels like there is some 
underlying issue that isn’t being fully communicated.

--Jens

From: Owen Nichols 
Date: Thursday, May 6, 2021 at 9:12 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode
A PR in "Draft" mode simply conveys that at least one more commit is coming 
before it will be "done".  Reviewers generously volunteer their time to look at 
your PR, and are welcome to look at it while in draft mode if they wish, but if 
they are quite busy, some may prefer to wait until the PR is plausibly 
code-complete before setting aside time to review it.

Sorry if I wasn't clear, I don't mean that flaky failures should mean a PR is 
not done.  You can always refer to the latest mass test report for a list of 
known flaky failures, but often I will see those and retrigger them for you 
anyway.

I expect that most PR submitters will be monitoring their own PR checks and 
taking it back to draft mode as soon as they realize more changes are needed.  
But if as a community we agree to use draft mode to communicate status in this 
way, it shouldn't matter who does it.

Due to CODEOWNERS, some reviewers have a huge number of PRs in their queue.  
Clearly communicating the status of your PR allows reviewers to focus their 
time on PRs that are ready for review.

On 5/6/21, 8:51 AM, "Jens Deppe"  wrote:

Comments inline…

Please keep your PR in draft mode anytime it is not ready to be reviewed.

This includes if you have received request for changes, or if any PR checks 
are not passing.

How do I know if everyone is done reviewing? Or even who might be 
reviewing? Different reviewers may be looking at different areas, depending on 
the scope of the change. If the PR suddenly switches back to ‘Draft` what does 
that mean if I’m reviewing it? Worse still, if I’m the owner and someone else 
switches it to Draft I’m not notified.

Additionally, many PR checks fail for reasons unrelated to the PR so 
switching blindly to ‘Draft’ seems pointless.


If you’re reviewing someone’s PR, and notice any checks not passing or you 
are requesting changes, please also click “Convert to draft”.

I really don’t agree with this – if you have an issue with a PR for 
whatever reason, please respect the author and address it directly with them. I 
certainly feel uncomfortable ‘messing’ with someone else’s PR and, by the same 
token, don’t want my PRs adjusted without my input.

--Jens

Re: Reminder to use draft mode

[Jens Deppe]

Comments inline…

Please keep your PR in draft mode anytime it is not ready to be reviewed.

This includes if you have received request for changes, or if any PR checks are 
not passing.

How do I know if everyone is done reviewing? Or even who might be reviewing? 
Different reviewers may be looking at different areas, depending on the scope 
of the change. If the PR suddenly switches back to ‘Draft` what does that mean 
if I’m reviewing it? Worse still, if I’m the owner and someone else switches it 
to Draft I’m not notified.

Additionally, many PR checks fail for reasons unrelated to the PR so switching 
blindly to ‘Draft’ seems pointless.


If you’re reviewing someone’s PR, and notice any checks not passing or you are 
requesting changes, please also click “Convert to draft”.

I really don’t agree with this – if you have an issue with a PR for whatever 
reason, please respect the author and address it directly with them. I 
certainly feel uncomfortable ‘messing’ with someone else’s PR and, by the same 
token, don’t want my PRs adjusted without my input.

--Jens

[RFC PROPOSAL] Geode Compatibility with Redis data sharding and cluster changes

[Jens Deppe]

Hello All,

This is a proposal to introduce cluster support for the Geode Compatibility 
with Redis module:

https://cwiki.apache.org/confluence/display/GEODE/Geode+Compatibility+with+Redis+data+sharding+and+cluster+changes

As per RFC guidelines, please comment in this thread.

Thanks
--Jens

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Jens Deppe]

I'd volunteer to do that.

If it gets deleted and then 'revived' under another repo, does that still 
require it to be an Apache project? What are the requirements?

--Jens

On 3/30/21, 8:02 AM, "Bruce Schuchardt"  wrote:

Does anyone want to take on the work of moving these sub-projects to 
another repository?  I picked up the ticket because it's costing us development 
and testing time but am not interested in being the owner of it in some other 
repo.


On 3/30/21, 5:45 AM, "Joris Melchior"  wrote:

+1 On this approach. If we could somehow have side project to implement 
this I think it would be really helpful. 

I also think it's less intimidating to contribute to for a lot of 
people.

Joris

On 2021-03-29, 2:55 PM, "John Blum"  wrote:

How hard is it to put the work like Protobuf in a separate 
repository (attached to Geode in some way)? I am not sure what the (Apache) 
procedure is.

We need stop baking everything into the "core" of Apache Geode.  
Most things that are non-essential (meaning, they are not required for Geode to 
carry out its primary responsibility as a data store, also & e.g. Redis 
Adapter) should be an "extension" (add-on), enabled with a plugin.

I fear this work would get lost if removed completely.  How would 
new (or even existing members) know where to find this work if interested? 
Branches are not a good alternative. A separate repo would make the entire 
process (e.g. releases) easier, not unlike the Kafka connector, or even Spring 
Data for that matter.

$0.02
-j


From: Bruce Schuchardt 
Sent: Monday, March 29, 2021 11:41 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

That's true John, but the Protobuf i/f is using the same code as 
the REST server to serialize/deserialize JSON documents.  It isn't any better 
at it.

On 3/29/21, 10:33 AM, "John Blum"  wrote:

Correction! Although a different/separate issue, Geode's JSON 
document handling is incomplete at best. It does not properly handle all forms 
of JSON or types (e.g. Java 8 Data/Time types).

From: Bruce Schuchardt 
Sent: Thursday, March 25, 2021 8:01 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf 
client/server interface

I worked on the protobuf client/server interface as long as 
anyone else but still fail to see the value in keeping it in anything but a 
branch unless someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for 
storing Json documents and we never got beyond that as cache values with the 
protobuf i/f.  People want to store data in Geode in a way that works with 
queries, delta propagation and other advanced features.  That was, and remains, 
the main problem for this interface.  Without that it's not even as good as the 
current REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became 
available as it allowed for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cjdeppe%40vmware.com%7C01ffb8cfb18849bc16eb08d8f38cd318%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637527133457524428%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=m3o05hvXMcD9icL%2F4SmxPT2amv0cqP%2BIEn6U%2Fz3ZMy8%3Dreserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding.

When considering various popular libraries/frameworks, they 
all have multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little 
while, although not for as long as some of the other folks commenting. I'm ok 
with removing it. I do see some value in leaving stalled/incomplete projects 
around as bait for future developers to pick up - that seems to have worked for 
redis ;) But if it is a maintenance burden lets drop it from develop. Someone 
can always pick it up from th

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Jens Deppe]

I was very excited when the protobuf support became available as it allowed for 
the fairly quick development of a Go client. 
(https://github.com/gemfire/geode-go-client). As Udo already mentioned, 
removing this functionality reduces our potential exposure to new use cases and 
language bindings. Just because it isn't 'feature complete' doesn't mean it 
isn't useful to someone. In fact, just today, somebody reached out regarding 
the Go binding. 

When considering various popular libraries/frameworks, they all have multiple 
bindings. Some of those are core to the library, but many are maintained 
separately. Having a well-defined protocol for Geode is the first step in 
making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, although not 
for as long as some of the other folks commenting. I'm ok with removing it. I 
do see some value in leaving stalled/incomplete projects around as bait for 
future developers to pick up - that seems to have worked for redis ;) But if it 
is a maintenance burden lets drop it from develop. Someone can always pick it 
up from the history.

If I recall correctly, one of the big incomplete parts of the project is 
that we hadn't figured out how to serialize user objects efficiently with this 
protocol. The default was to convert PDX objects to JSON. That was about as 
efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

As the only remaining member on the CSharpDriver team, I too have an 
attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should have put all the resources on the 
server side, as the client implementation was almost trivial.

Mike


---
Sent from Workspace ONE 
Boxer

On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer  wrote:
Alexander, as you know, the intent for this work was to lower the barrier 
of entry, as the Geode wire protocol is not documented, which makes it 
impossible to contribute any clients in other languages to the project. The 
lack of documentation of this feature did also not help the case.

If no-one else sees ANY benefit of having a self-describing wire protocol 
as part of the project, then you should remove it. But as stated, without AND 
documentation pertaining to the wire protocol for Geode, removing the only 
self-describing protocol with serialization, adopted by many globally, will put 
the barrier of entry of contributing to Geode, outside of Java and C++/C# even 
higher.

In addition, I'm sure that the contributors to the C++/C# client could 
actually benefit in using this protocol.

But I am just a single voice.

--Udo

On 3/24/21, 9:38 AM, "Alexander Murmann"  wrote:

Udo, having worked on Protobuf with you, I share the emotional 
attachment. I also agree that it's a valuable feature to have and that ideally 
someone would pick it up. I don't think it's feature complete enough at this 
point to be viable. Unlike with Redis, I haven't seen anyone in the community 
contribute to it in a long time. If you or someone else were to volunteer to do 
all the work you propose we do on Protobuf, I'd strongly support keeping it.

I think each of the other feature areas you propose as potential 
removal candidates deserve their own dedicated discussion. I understand some of 
them are harder to remove from a technical perspective or neither experimental 
nor deprecated and would thus require a Geode 2.0.

From: Udo Kohlmeyer 
Sent: Tuesday, March 23, 2021 14:54
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

-1

Given that I was on the team that started this initiative, I will 
naturally have an inclination to say 'No'.

I don't know if I would go as far as removing this 

Re: PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Jens Deppe]

Sorry, I forgot to add that this proposal is to backport to 1.14.0

On 3/19/21, 7:35 AM, "Jens Deppe"  wrote:

This work builds on GEODE-9023 which added sharding support to the 
compatible with Redis region.

This change cleans up data structures and will allow for easier, future 
rolling upgrades and data migrations if necessary.

Thanks
--Jens

PROPOSAL: Backport GEODE-9044 - Introduce RedisKey as key object for RedisData entries

[Jens Deppe]

This work builds on GEODE-9023 which added sharding support to the compatible 
with Redis region.

This change cleans up data structures and will allow for easier, future rolling 
upgrades and data migrations if necessary.

Thanks
--Jens

[PROPOSAL]: Backport redis-compatibility changes to 1.14 - GEODE-9021 and GEODE-9023

[Jens Deppe]

These changes relate to Redis-compatibility which will be enabled and 
non-experimental in 1.14

GEODE-9021: Avoid unnecessary buffer creation in redis Coder

  *   Provides performance improvements in terms of CPU and memory usage

GEODE-9023: Add sharding support to redis region

  *   This change introduces a partition resolver which will allow for future 
compatibility with redis cluster-aware clients. Having this in place now will 
reduce the complexity for future rolling upgrades when cluster support is fully 
provided.

Thanks
--Jens

Re: [Poposal] Backport GEODE-9019 to Apache Geode 1.14.0 branch

[Jens Deppe]

+1

On 3/11/21, 10:49 AM, "Nabarun Nag"  wrote:

Hi everyone,

Putting forward the proposal to backport GEODE-9091 (Serialization 
Improvements) to support/1.14 branch,

What does GEODE-9091 do?

  *   It adds serialVersionUID to the Serializable classes in geode-redis 
module
  *   It converts all DataSerializable classes to DataSerializableFixedID 
classes

Why do we need to backport these changes?

  *   These changes future-proofs the geode-redis data structures from 
being used in mixed version clusters.
  *   This will ensure that changes to serializable classes do not break 
backward compatibility.
  *   If these classes get changed in the future, the serialVersionUIDs 
will remain the same and can be used with older and newer versions.
  *   If we don't backport these changes to 1.14.0 then future releases of 
geode-redis will not be compatible with it.

Reference 
PR:[link]


Regards
Nabarun Nag

Re: Concourse Access

[Jens Deppe]

Ditto for me please: jdeppe-pivotal

--Jens

On 2/5/21, 9:08 AM, "Jacob Barrett"  wrote:

May I please have my Concourse access restored.

GitHub: pivotal-jbarrett

Thanks,
Jake

Re: create region and clear entries from geode-client

[Jens Deppe]

Hi Ankit!

For function execution, I'd point you to the geode examples repo which has a 
simple example for functions [1]. Once you see how that works, it should be 
fairly straight forward to integrate the code you linked. When using functions, 
there are a couple of things to be aware of:

Your function code needs to be on the classpath of the servers. You can achieve 
this either by starting the servers with the '--classpath' option and point 
that at your jar, or you can use the 'gfsh deploy' jar to make your jar 
available to all the servers once they are running.

'Manual' region creation is somewhat cumbersome in older versions of Geode. 
Specifically because you will need to execute your function on each server that 
should host the region. It's easy when you're developing locally, but 
definitely becomes a little more involved when you have a larger cluster.

Of interest to you may be a new experimental feature which provides an API for 
the java client to create regions. Here is a short example:

ClientCacheFactory factory = new ClientCacheFactory()
.addPoolLocator("localhost", 10334);
ClientCache cache = factory.create();

Region regionConfig = new Region();
regionConfig.setName("REGION1");
regionConfig.setType(RegionType.REPLICATE_PERSISTENT);

ClusterManagementService service =
new GeodeClusterManagementServiceBuilder()
.setCache(cache)
.build();

service.create(regionConfig);

This functionality should be available in Geode 1.13.

Hope this helps.

--Jens

[1] https://github.com/apache/geode-examples/tree/develop/functions

On 12/17/20, 4:51 AM, "ankit Soni"  wrote:

Hello,

I have started using geode (1.12) in recent time and  looking to achieve
the following from a *java based geode-client program.*

 1.* create REPLCIATED and PARTITION regions from the client itself and
while creating it, need to provide a config that deletes the entries at
specified time.*

 2. *clear entries of a region from the client..*

I am exploring geode doc and have come across the following but unable to
understand what code i need to write in the geode-client java program.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F14%2Fdeveloping%2Fregion_options%2Fdynamic_region_creation.htmldata=04%7C01%7Cjdeppe%40vmware.com%7C5995825d4e4349282fc408d8a28a858c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637438063154882742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Wfl62xoUDg2jL408T6%2BCg3yaYE2yiZh0blWiDYLr%2FaA%3Dreserved=0

Can some guide me on how to achieve this...?

-Ankit.

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

[Jens Deppe]

I've self-nominated for redis, management and security.

--Jens

On 12/14/20, 1:44 AM, "Owen Nichols"  wrote:

Thanks @Dave and @Karen for volunteering as code owners!

The Dec 14 deadline @Robert set is today.  So far 11 of the 268 slots have 
been filled.

To volunteer, follow these steps:
  cd geode
 git checkout feature/introduce-codeowners
 git pull
 vi CODEOWNERS
  git add CODEOWNERS
 git commit -m "I volunteered"
 git push

You may need to uncomment the line if you’re the first to append your 
@githubusername.
Two or more volunteers on each line is desirable.

From: Owen Nichols 
Date: Monday, December 7, 2020 at 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
Let’s keep this simple.  If you’re nominating yourself, just commit to the 
branch directly.  If you wish to nominate someone else, make a PR and tag them 
as a reviewer.

From: Robert Houghton 
Date: Monday, December 7, 2020 at 1:38 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
To be honest, I hadn’t thought of the mess that might make. I guess, we can 
either make changes directly to the feature branch, which will eventually have 
a pull-request back to [develop], or we can modify Owen’s existing PR. At the 
end of the day, it all has to go through the normal PR process back to the 
develop branch.

    -Robert

From: Jens Deppe 
Date: Monday, December 7, 2020 at 11:43 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
Should we just be adding to Owen's PR?

If everyone creates their own PR we'll probably end up with a bunch of 
merge conflicts.

--Jens

On 12/7/20, 10:07 AM, "Robert Houghton"  wrote:

I haven’t seen any negative responses, and a big THANK YOU to @onichols 
for making the first PR to self-volunteer into ownership of some code. Lets 
give people another week to nominate, or self-nominate, as PRs against 
[feature/introduce-codeowners], and plan to merge this feature into develop on 
14 December?




From: Owen Nichols 
Date: Tuesday, December 1, 2020 at 8:56 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
It looks like the discussion period ended Nov 25 with all comments in 
support, so next phase is populating the proposed codeowners file.  @Robert how 
long do we have to populate this before you plan to formally propose activating 
it on develop?

As prescribed I’ve submitted a PR[1] against the 
feature/introduce-codeowners branch to nominate myself as a code owner for 
areas I feel qualified to own.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5802data=04%7C01%7Cjdeppe%40vmware.com%7Cd600a63c23ef4da0212108d8a014d09d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637435358557517682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ttcG7%2F%2BvDbLcPsRW754jcEcB3s5LflMN9D0jol1sa94%3Dreserved=0

From: Xiaojian Zhou 
Date: Friday, November 20, 2020 at 11:06 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
+1

I saw the template of splitting the geode code. Can someone nominate a 
few codeowners in the file as examples?

On 11/20/20, 7:32 AM, "Alexander Murmann"  wrote:

+1

I agree with Owen's point that this will improve the experience for 
new contributors. It also helps people new to the community to have confidence 
that they got the type of review they need to feel confident to merge. I might 
get to reviews that are both from great committers who can review for things 
like coding style, test coverage etc. However, I might be unaware that neither 
of them know the area I am modifying particularly well. This solves this 
problem. I can merge with more confidence, once I got the review from the owner.

From: Anthony Baker 
Sent: Thursday, November 19, 2020 17:55
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

+1

I think we as a project will need to iterator on the code owners as 
well as the process for code owners.  But this is a model that has been adopted 
by a number of OSS projects both within and outside of Apache.  I like that it 
provides visibility to PR authors and associates motivated experts to review 
and merge changes.

Anthony


> On Nov 19, 2020, at 10:46 AM, Ernie Burghardt 
 wrote:
>
> Perfect, then let's give this a try.
> +1
>
   

Re: [Proposal] - Cleanup Protocol Version Checks

[Jens Deppe]

+1 Good suggestion.

I have no idea what the scope of the cleanup looks like, but it seems like an 
excellent entry-point for newcomers to the codebase to get their hands dirty.

I know this is a weird request, but I'd like to ask committers not to jump on 
this, but allow some time for non-committers to pick this up and get some PRs 
under their belts.

Thanks
--Jens

On 12/8/20, 2:38 PM, "Jacob Barrett"  wrote:

We all do lots of cleanup as we go through areas of the source, like 
optimizing lambda expressions, renaming variables with more meaningful names 
and deleting commented out code, just to name a few. Littered throughout the 
network protocol sources are checks for older protocol versions. Lots of these 
checks go back to versions of the original product Geode was granted. Some of 
those versions date back a decade or more. It is undoubtably filled with 
obsolete bits of unexecuted code.

I propose that we cleanup, as we go through sources for other changes, all 
checks for versions older than GFE_82 AKA GFE_82_ORDINAL AKA 40. This allows 
for clients just a single minor older than the first Geode incubating release 
to continue to work with Geode 1.x for the purpose of uninterrupted rolling 
upgrades. Upon the eventual move to Geode 2.x we would agree on some new 
minimum backwards compatibility version of Geode 1.x to clean up to.

Removing this old compatibility code should remove a significant number of 
unused branches of source and improve the readability of methods littered with 
version checks.

Examples:

BaseCommand.java:216 (BaseCommand::shouldMasqueradeForTx):

protected boolean shouldMasqueradeForTx(Message clientMessage,
ServerConnection serverConnection) {
  return 
serverConnection.getClientVersion().isNotOlderThan(KnownVersion.GFE_66)
  && clientMessage.getTransactionId() > TXManagerImpl.NOTX;
}

Becomes:

protected boolean shouldMasqueradeForTx(Message clientMessage) {
  return clientMessage.getTransactionId() > TXManagerImpl.NOTX;
}

Even further, since this method is only used in a single place it could be 
easily inlined and maintain readability.

ClientSideHandshakeImpl.java:170 
(ClientSideHandshakeImpl::handshakeWithServer) has 4 different version checks 
in the same method and could be reduced to 1.


To facilitate these changes I also propose that we update the handshakes to 
deny connections if the protocol version is less than GFE_82. Doing so will 
prevent an older client from sort of working and failing in spectacular and 
undefined ways. I would also like to deprecate, with annotations, the older 
version constants so that they stand out as needing to be pruned when you are 
editing sources.


To reiterate this isn’t a proposal to open a PR to strip out all the old 
versions in one shot. It is a proposal to remove them when submitting PRs in an 
area of code that has them.


Feedback appreciated by 12/18 before a formal acceptance vote is requested.

Thanks,
Jake

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

[Jens Deppe]

Should we just be adding to Owen's PR?

If everyone creates their own PR we'll probably end up with a bunch of merge 
conflicts.

--Jens

On 12/7/20, 10:07 AM, "Robert Houghton"  wrote:

I haven’t seen any negative responses, and a big THANK YOU to @onichols for 
making the first PR to self-volunteer into ownership of some code. Lets give 
people another week to nominate, or self-nominate, as PRs against 
[feature/introduce-codeowners], and plan to merge this feature into develop on 
14 December?




From: Owen Nichols 
Date: Tuesday, December 1, 2020 at 8:56 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
It looks like the discussion period ended Nov 25 with all comments in 
support, so next phase is populating the proposed codeowners file.  @Robert how 
long do we have to populate this before you plan to formally propose activating 
it on develop?

As prescribed I’ve submitted a PR[1] against the 
feature/introduce-codeowners branch to nominate myself as a code owner for 
areas I feel qualified to own.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5802data=04%7C01%7Cjdeppe%40vmware.com%7C084ca28d6dcb42ad745808d89adaec2f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637429612370461181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sTI13sffzczWq1%2F9LGJ0IAueRds%2F80TLAPIlQ5defIA%3Dreserved=0

From: Xiaojian Zhou 
Date: Friday, November 20, 2020 at 11:06 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
+1

I saw the template of splitting the geode code. Can someone nominate a few 
codeowners in the file as examples?

On 11/20/20, 7:32 AM, "Alexander Murmann"  wrote:

+1

I agree with Owen's point that this will improve the experience for new 
contributors. It also helps people new to the community to have confidence that 
they got the type of review they need to feel confident to merge. I might get 
to reviews that are both from great committers who can review for things like 
coding style, test coverage etc. However, I might be unaware that neither of 
them know the area I am modifying particularly well. This solves this problem. 
I can merge with more confidence, once I got the review from the owner.

From: Anthony Baker 
Sent: Thursday, November 19, 2020 17:55
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

+1

I think we as a project will need to iterator on the code owners as 
well as the process for code owners.  But this is a model that has been adopted 
by a number of OSS projects both within and outside of Apache.  I like that it 
provides visibility to PR authors and associates motivated experts to review 
and merge changes.

Anthony


> On Nov 19, 2020, at 10:46 AM, Ernie Burghardt  
wrote:
>
> Perfect, then let's give this a try.
> +1
>
> On 11/19/20, 10:45 AM, "Robert Houghton"  wrote:
>
>Hi Ernie,
>
>DRAFT PRs do not get reviewers by default, but when the draft 
transitions to ‘ready’, then the owners are requested to review.
>
>
>From: Ernie Burghardt 
>Date: Thursday, November 19, 2020 at 9:56 AM
>To: dev@geode.apache.org 
>Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
>Does GitHub allow us to limit this automated action to non-DRAFT 
PRs?
>
>On 11/18/20, 8:28 PM, "Owen Nichols"  wrote:
>
>+1 This will greatly improve the experience for contributors.  
Instead of an intimidating empty list of reviewers when you submit a PR (and no 
ability to add reviewers, if you’re not a committer), it will be great to 
already have at least two reviewers automagically assigned.
>
>I have a small concern that initially populating this file via 
a flurry of PRs may result in a lot of merge conflicts with anyone else that 
volunteers on the same or an adjacent line.  Also, since you _must_ be a 
committer to be a code owner, is a PR even necessary…would directly committing 
changes to the feature/introduce-codeowners branch be acceptable?  If not, who 
needs to review and who can merge the PRs against the ‘introduce’ branch?
>
>What happens if you are the only owner for an area, can you 
approve your own PR?  Even if the goal is two owners per area, does that mean 
PRs by either owner cannot be merged if the only other owner is on vacation or 
otherwise unavailable?
>
>Can we submit PRs against the ‘introduce’ branch now and they 
just won’t be merged before Nov 26, or do we all just need to be patient until 
this review period 

Re: [DISCUSS] Geode 1.14

[Jens Deppe]

Hi Owen,

Thanks for starting this conversation and especially for volunteering as 
Release Manager!

Since we're already a couple of quarters 'behind', in terms of releases, I'd 
prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 
months of changes to stabilize. How long might that take to finally get 
shipped? (rhetorical).

--Jens

On 11/25/20, 6:05 PM, "Owen Nichols"  wrote:

The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met 
(we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch.  I will volunteer 
as Release Manager.

Below are all release dates since Geode adopted a time-based release 
cadence.

Minor releases:
1.13   branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12   branch cut Feb 4 20201.12.0 shipped Mar 31 2020
1.11   branch cut Nov 4 2019   1.11.0 shipped Dec 31 2019
1.10   branch cut Aug 2 2019   1.10.0 shipped Sep 26 2019
1.9  branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8  branch cut Nov 1 2018   1.8.0 shipped Dec 12 2018

Patch releases:
1.13.1shipped Nov 18 2020
1.9.2  shipped Nov 14 2019
1.9.1  shipped Sep 6 2019

I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on 
the next date in the original quarterly cadence: Feb 1 2021.

-Owen

From: Alexander Murmann 
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org 
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,

As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.

Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.

Short how-to on running a geode cluster in docker containers

[Jens Deppe]

I recently had the need to run a geode cluster in docker containers and thought 
my findings and script might be useful. I’ve created a wiki page here: 
https://cwiki.apache.org/confluence/display/GEODE/Running+a+Geode+cluster+in+docker

The reason for this was that I wanted to easily be able to use my geode build 
inside a geode/docker cluster for quick iteration. A secondary need was to be 
able to constrain the resources used by each member. Since docker allows CPU 
constraints I could simulate running on a ‘smaller’ system by just assigning a 
specific number of CPUs to each container.

Please let me know if you have any questions.

--Jens

[DISCUSS] Run subclassed tests in StressNewTest

[Jens Deppe]

Hello fellow Devs,

This is really more of a ‘heads-up’ message.

Some of our test code is codified in abstract classes that are then extended by 
other classes which, perhaps, do specialized set up or whatever. (The Redis 
team does this where we run the same tests against both native Redis and the 
Geode Redis implementation). A problem with this is that making a change to the 
actual test (in an abstract class) does not result in the classes being run by 
StressNewTest.

To that end I have a PR which will discover (and run) any subclasses of changed 
tests as part of StressNewTest. (https://github.com/apache/geode/pull/5601).

As an example, If I make a change to AbstractInfoIntegrationTest, StressNewTest 
will now run InfoIntegrationTest and InfoNativeRedisIntegrationTest.

Since we’re potentially going to run more tests, I’ve increased the maximum 
changed test threshold from 25 files/classes to 35. The overall timeout for the 
CI job has been increased from 6 to 10 hours.

Let me know if you have any concerns regarding this change, otherwise I’ll be 
putting it into effect in the next day or so.

Thanks
--Jens

Re: [DISCUSS] ServiceRegistry RFC

[Jens Deppe]

One aspect this conversation has brought to mind is whether these services will 
require some kind of lifecycle management? If any of them require an instance 
of a Cache (and perhaps other components) they will need to be aware of the 
cache restarting (happens during reconnect).

Is that going to be a problem?

--Jens

On 10/20/20, 1:12 PM, "Udo Kohlmeyer"  wrote:

Hi there Dan,

We (Patrick and I) are in violent agreement about adding new singletons to 
the product. This singleton is merely there to avoid the complete utter 
re-write of the system to wire in said ServiceRegistry into the cache.

Yes, we are merely replacing 1 singleton with another, but we see it as a 
step in the right direction that we are replacing the usage with a generic 
service based implementation, that would allow for the simple “swap-in/out” of 
class loading (GEODE-8067).

Our inspiration for this ServiceRegistry is from Spring’s 
ApplicationContext, without all of the cool DI features that Spring would 
bring. We just needed a single location where one could add services and lookup 
them up.

We agree, singletons are bad. But hanging everything off InteralCache 
without a better designed lifecycle for module/component creation would make no 
sense. THAT is a design that we need to look at to better structure/separate 
modules/components.

Whilst doing GEODE-8466, and the replacing of ClassPathLoader with an 
instance-based ClassLoaderService, we found MANY static methods/functions that 
used the singleton ClassPathLoader, without ANY possibility to be able to wire 
in a ServiceRegistry instance. In addition, the current singleton is merely 
reducing the number of files that we need to alter to get this added. We had 
(from initial GEODE-8466) implementations, learned that passing in a 
ClassLoaderService instance into each Class/Method that required it, meant we 
touched 330+ classes. In addition those changes were BEFORE we attempted to 
replace the static usages of ClassPathLoader with ClassLoaderService.

I imagine that the casuality list of Classes touched would be much higher 
than 330 if we attempted the same approach with ClassPathLoader. In addition to 
the crazy effort we’d have to go through to replace the static method/code 
block usages of ClassPathLoader with instance references to ClassLoaderService.

--Udo

From: Dan Smith 
Date: Wednesday, October 21, 2020 at 5:14 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC
It might be better to hang things off InternalCache rather than create a 
new singleton. The cache is already a singleton, but we've been working on 
removing that by plumbing the cache everywhere. The cache is effectively our 
context object, and once we've finished removing calls to Cache.getInstance we 
will have a context object that is not a singleton.

As Jens mentioned, the cache already has the concept of CacheServices that 
can be retrieved using methods similar to what you listened in this RFC - eg 
InternalCache.getService(Class clazz).

Can we reuse/generalize/extend this existing service concept for your case?

-Dan

From: Jens Deppe 
Sent: Tuesday, October 20, 2020 5:33 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] ServiceRegistry RFC

Hi Udo,

Is the intention of this to replace (and extend) what we're doing with the 
traditional service loading mechanism today? i.e. how we're loading everything 
that extends CacheService (for example HttpService, LuceneService, 
GeodeRedisService, etc.).

Thanks
--jens



On 10/15/20, 7:25 PM, "Udo Kohlmeyer"  wrote:

Hi there Apache Geode Devs.

Please find attached an RFC for the introduction of a ServiceRegistry 
into Apache Geode.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FServiceRegistrydata=04%7C01%7Cjdeppe%40vmware.com%7Cb2a0e69779a74f141b7108d87534841b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637388215707347503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5Z6jcDR31xycOX9pBDRBl%2B7aBkHloSI6De6XjGY3lO0%3Dreserved=0

Please add all comments to the RFC to this email for tracking and 
discussion.

--Udo

Re: [DISCUSS] ServiceRegistry RFC

[Jens Deppe]

Hi Udo,

Is the intention of this to replace (and extend) what we're doing with the 
traditional service loading mechanism today? i.e. how we're loading everything 
that extends CacheService (for example HttpService, LuceneService, 
GeodeRedisService, etc.).

Thanks
--jens



On 10/15/20, 7:25 PM, "Udo Kohlmeyer"  wrote:

Hi there Apache Geode Devs.

Please find attached an RFC for the introduction of a ServiceRegistry into 
Apache Geode.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FServiceRegistrydata=04%7C01%7Cjdeppe%40vmware.com%7C2992b6fe368a40379f3708d8717ac518%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637384119403978572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3WLpKRKqQecQuLfoX7M18OCw4P8%2Brv0xNLqoX%2FUJ0eo%3Dreserved=0

Please add all comments to the RFC to this email for tracking and 
discussion.

--Udo

Re: [Discussion] - ClassLoaderService RFC proposal

[Jens Deppe]

Thanks for this work Udo!

Does this ClassLoaderService effectively replace the current ClassPathLoader 
mechanism then?

How will one access the service; is there some static reference? Some code 
examples would be helpful to properly understand how one might work with this.

--Jens

On 9/14/20, 3:42 AM, "Udo Kohlmeyer"  wrote:

Hi there Apache Geode Devs, (try 2)

Please find attached a proposal for a ClassLoaderService. Please review and 
ponder on it.


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduction%2Bof%2BClassLoaderService%2Binto%2BGeodedata=02%7C01%7Cjdeppe%40vmware.com%7Cde083e2172634f2bf11b08d8589ae7dc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637356769623047129sdata=VkXprwOM%2FzGXO%2FYMOoBMC60kiREyagn%2B6%2F%2FSvajv9Tg%3Dreserved=0

All comments are please to be made in this mail thread.

—Udo

Re: [VOTE] Apache Geode 1.13.0.RC1

[Jens Deppe]

+1

Actions performed:

- Downloaded product .tgz bundle from maven co-ordinates
- Verified GemFireVersion.properties matched SHA for 1.13.0 build tag
- Started cluster with SSL enabled and ensured basic GFSH operations over HTTPS
- Connected GFSH v1.13.0 to newer cluster running v1.14.0

--Jens

On 9/7/20, 8:23 PM, "Dave Barnes"  wrote:

Hello Geode Dev Community,


This is a release candidate for Apache Geode version 1.13.0.RC1.

Thanks to all the community members for their contributions to this release!


Please do a review and give your feedback, including the checks you
performed.


Voting deadline:

3PM PDT Wed, September 9, 2020.


Please note that we are voting upon the source tag:

rel/v1.13.0.RC1


Release notes:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.0data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=66ODWpIM6Cl%2BiMOhqxz5brFdHvuO%2FoPSxFFxs6AMyO0%3Dreserved=0


Source and binary distributions:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1%2Fdata=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=Johm3hoxjQ6%2BhahnhSpRnL1z6sp1RNlM3c75QSc7XVI%3Dreserved=0


Maven staging repo:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1069data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=jVV5xDKAnsgWU9hc5cykQS9214Mo%2FINrpI2BlLQaibc%3Dreserved=0


GitHub:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=iH1Hoz7ERg5FJkd9eA5BeJjqwHrWGCfzIVNkeIPdT9U%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=FGBAj3MWW19KChiARTkos%2F7HYDGjiX4tlgrptl0SF38%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=P%2BBWL2v%2B4SAVgDUnkww5qELkQab0SnM%2F8uctwWvzD1c%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.0.RC1data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=7v5Ij62R3qj0L%2FGIfgcqZmF0r3H9LMuPdECi%2FDD2d5A%3Dreserved=0


Pipelines:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=nBxzHIby6kSq49AjwazPCkYy5%2BocuFkWHMKPYVAyNBI%3Dreserved=0


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=5M7vWMR8oNwDmQYGe5DT7oxWiZmBnFLRomsApunm9js%3Dreserved=0


Geode's KEYS file containing PGP keys we use to sign the release:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYSdata=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069974184sdata=tyNRtD4lzdjL2iTESrOUwEFbf2vdw2oxLdNqn462cMU%3Dreserved=0


Command to run geode-examples:

./gradlew -PgeodeReleaseUrl=

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.0.RC1data=02%7C01%7Cjdeppe%40vmware.com%7C63ee1ef527dd4055b90508d853a68c51%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637351322069984183sdata=FQj%2Fdg2bMnw4nytWhRnuiQV4Peo%2FIP2KCp2DJuMls%2Fk%3Dreserved=0
-PgeodeRepositoryUrl=

Re: Docker on Windows

[Jens Deppe]

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

--Jens

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

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


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

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

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

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

-Jake

Re: [PROPOSAL] Add windows jobs to PR checks

[Jens Deppe]

It's been a couple of years since Sai and I tried (but failed) to dockerize the 
tests. I'm sure docker support has improved and it might be worth trying that 
again.

--Jens

On 6/25/20, 10:08 AM, "Jacob Barrett"  wrote:



> On Jun 25, 2020, at 10:01 AM, Jinmei Liao  wrote:
> 
> +1, what was the reason for it not being included the PR before?

The Windows integration and acceptance tests take a very long time to run 
because we can’t dockerize and parallelize them. They have also be very flaky 
in the past. 

Commit revert etiquette

[Jens Deppe]

Hello friends,

Just recently I’ve noticed a couple of PRs submitted that were intended to 
revert flaky or suspected commits. Initially, these PRs were simply marked as 
‘Revert’ without any further detail. I’m not sure if there was any additional 
out-of-band communication but I would like to request that that if you’re 
submitting a reversion you do the courtesy of providing additional details as 
to why the commit is being reverted. That way it is also obvious to others, who 
may not be aware of additional communication, what the reason is.

Thank you.
--Jens

Re: Redis PubSubTest started failing

[Jens Deppe]

Not at this time since I do believe the issue is just a flaky test and not
a flaky implementation.

I've merged in the change to ignore this test for now.

--Jens

On Wed, Feb 19, 2020 at 9:46 AM Udo Kohlmeyer  wrote:

> Does that mean we will revert from develop pls?
>
> On 2/19/20 9:33 AM, Jens Deppe wrote:
> > Me too :)
> >
> > I've had it pass several StressNewTest runs but yet, it seems to still
> fail
> > at times.
> >
> > On Wed, Feb 19, 2020 at 9:29 AM Kirk Lund  wrote:
> >
> >> PubSubTest now fails for me in every PR I submit (3 yesterday). I'm
> really
> >> curious how this change made it past PR and into develop.
> >>
> >> On Wed, Feb 19, 2020 at 9:18 AM Kirk Lund  wrote:
> >>
> >>> PubSubTest is an integration test. Confusion from test names is why I
> >>> prefer to include *IntegrationTest or *DistributionTest in the name
> like
> >>> the wiki prescribes. I recommend naming this test
> PubSubIntegrationTest.
> >>>
> >>> On Wed, Feb 19, 2020 at 9:06 AM Owen Nichols 
> >> wrote:
> >>>> StressNew is cross-cutting. Unit tests are historically the very least
> >>>> likely to exhibit windows-specific modes of failure.
> >>>>
> >>>> On Wed, Feb 19, 2020 at 9:02 AM Robert Houghton  >
> >>>> wrote:
> >>>>
> >>>>> We don't even have windows unit tests for PRs. Walk before we run...
> >>>>>
> >>>>> On Wed, Feb 19, 2020, 09:00 Owen Nichols 
> wrote:
> >>>>>
> >>>>>> Perhaps also worth considering: can we get WindowsStressNew added to
> >>>> the
> >>>>> PR
> >>>>>> checks?
> >>>>>>
> >>>>>> On Wed, Feb 19, 2020 at 8:50 AM Udo Kohlmeyer 
> >> wrote:
> >>>>>>> Is this something that can be fixed in a short time (2hrs)? If
> >> not,
> >>>> can
> >>>>>>> be revert and get back to a clean pipeline?
> >>>>>>>
> >>>>>>> --Udo
> >>>>>>>
> >>>>>>> On 2/19/20 8:23 AM, Jens Deppe wrote:
> >>>>>>>> Thanks Kirk,
> >>>>>>>>
> >>>>>>>> We're working on fixing this.
> >>>>>>>>
> >>>>>>>> --Jens
> >>>>>>>>
> >>>>>>>> On Tue, Feb 18, 2020 at 3:23 PM Kirk Lund 
> >>>> wrote:
> >>>>>>>>> I just started seeing the Redis PubSubTest fail in
> >>>> IntegrationTest
> >>>>>> after
> >>>>>>>>> rebasing on develop this afternoon. Looks like I have Jens'
> >>>> latest
> >>>>>>> commit
> >>>>>>>>> for this test:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *commit 1befce17eaae2403828769840f86639e13fce81f
> >> (origin/develop,
> >>>>>>>>> origin/HEAD, develop)Author: Jens Deppe  >>>>>>>>> >Date:   Tue Feb 18 13:03:19 2020 -0800
> >>>>>>> GEODE-7798:
> >>>>>>>>> Fix flaky PubSub test (#4714)*
> >>>>>>>>>
> >>>>>>>>> *Authored-by: Jens Deppe  >>>> jde...@pivotal.io
> >>>>>>> Task
> >>>>>>>>> :geode-redis:integrationTest*
> >>>>>>>>>
> >>>>>>>>> Here's the stack traces:
> >>>>>>>>>
> >>>>>>>>> org.apache.geode.redis.PubSubTest > testPatternWithoutAGlob
> >>>> FAILED
> >>>>>>>>>   redis.clients.jedis.exceptions.JedisConnectionException:
> >>>>>>>>> java.net.SocketTimeoutException: Read timed out
> >>>>>>>>>   at
> >>>>>>>>>
> >>
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
> >>>>>>>>>   at
> >>>>>>>>>
> >>>&g

Re: Redis PubSubTest started failing

[Jens Deppe]

I've created a PR to ignore this test for now (GEODE-7798 is tracking the
problem).

On Wed, Feb 19, 2020 at 9:33 AM Jens Deppe  wrote:

> Me too :)
>
> I've had it pass several StressNewTest runs but yet, it seems to still
> fail at times.
>
> On Wed, Feb 19, 2020 at 9:29 AM Kirk Lund  wrote:
>
>> PubSubTest now fails for me in every PR I submit (3 yesterday). I'm really
>> curious how this change made it past PR and into develop.
>>
>> On Wed, Feb 19, 2020 at 9:18 AM Kirk Lund  wrote:
>>
>> > PubSubTest is an integration test. Confusion from test names is why I
>> > prefer to include *IntegrationTest or *DistributionTest in the name like
>> > the wiki prescribes. I recommend naming this test PubSubIntegrationTest.
>> >
>> > On Wed, Feb 19, 2020 at 9:06 AM Owen Nichols 
>> wrote:
>> >
>> >> StressNew is cross-cutting. Unit tests are historically the very least
>> >> likely to exhibit windows-specific modes of failure.
>> >>
>> >> On Wed, Feb 19, 2020 at 9:02 AM Robert Houghton 
>> >> wrote:
>> >>
>> >> > We don't even have windows unit tests for PRs. Walk before we run...
>> >> >
>> >> > On Wed, Feb 19, 2020, 09:00 Owen Nichols 
>> wrote:
>> >> >
>> >> > > Perhaps also worth considering: can we get WindowsStressNew added
>> to
>> >> the
>> >> > PR
>> >> > > checks?
>> >> > >
>> >> > > On Wed, Feb 19, 2020 at 8:50 AM Udo Kohlmeyer 
>> wrote:
>> >> > >
>> >> > > > Is this something that can be fixed in a short time (2hrs)? If
>> not,
>> >> can
>> >> > > > be revert and get back to a clean pipeline?
>> >> > > >
>> >> > > > --Udo
>> >> > > >
>> >> > > > On 2/19/20 8:23 AM, Jens Deppe wrote:
>> >> > > > > Thanks Kirk,
>> >> > > > >
>> >> > > > > We're working on fixing this.
>> >> > > > >
>> >> > > > > --Jens
>> >> > > > >
>> >> > > > > On Tue, Feb 18, 2020 at 3:23 PM Kirk Lund 
>> >> wrote:
>> >> > > > >
>> >> > > > >> I just started seeing the Redis PubSubTest fail in
>> >> IntegrationTest
>> >> > > after
>> >> > > > >> rebasing on develop this afternoon. Looks like I have Jens'
>> >> latest
>> >> > > > commit
>> >> > > > >> for this test:
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >>
>> >> > > > >> *commit 1befce17eaae2403828769840f86639e13fce81f
>> (origin/develop,
>> >> > > > >> origin/HEAD, develop)Author: Jens Deppe > >> > > > >> >Date:   Tue Feb 18 13:03:19 2020 -0800
>> >> > > > GEODE-7798:
>> >> > > > >> Fix flaky PubSub test (#4714)*
>> >> > > > >>
>> >> > > > >> *Authored-by: Jens Deppe > >> jde...@pivotal.io
>> >> > >>>
>> >> > > > Task
>> >> > > > >> :geode-redis:integrationTest*
>> >> > > > >>
>> >> > > > >> Here's the stack traces:
>> >> > > > >>
>> >> > > > >> org.apache.geode.redis.PubSubTest > testPatternWithoutAGlob
>> >> FAILED
>> >> > > > >>  redis.clients.jedis.exceptions.JedisConnectionException:
>> >> > > > >> java.net.SocketTimeoutException: Read timed out
>> >> > > > >>  at
>> >> > > > >>
>> >> > > >
>> >> >
>> >>
>> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
>> >> > > > >>  at
>> >> > > > >>
>> >> >
>> redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
>> >> > > > >>  at
>> >> redis.clients.jedis.Protocol.process(Protocol.java

Re: Redis PubSubTest started failing

[Jens Deppe]

Me too :)

I've had it pass several StressNewTest runs but yet, it seems to still fail
at times.

On Wed, Feb 19, 2020 at 9:29 AM Kirk Lund  wrote:

> PubSubTest now fails for me in every PR I submit (3 yesterday). I'm really
> curious how this change made it past PR and into develop.
>
> On Wed, Feb 19, 2020 at 9:18 AM Kirk Lund  wrote:
>
> > PubSubTest is an integration test. Confusion from test names is why I
> > prefer to include *IntegrationTest or *DistributionTest in the name like
> > the wiki prescribes. I recommend naming this test PubSubIntegrationTest.
> >
> > On Wed, Feb 19, 2020 at 9:06 AM Owen Nichols 
> wrote:
> >
> >> StressNew is cross-cutting. Unit tests are historically the very least
> >> likely to exhibit windows-specific modes of failure.
> >>
> >> On Wed, Feb 19, 2020 at 9:02 AM Robert Houghton 
> >> wrote:
> >>
> >> > We don't even have windows unit tests for PRs. Walk before we run...
> >> >
> >> > On Wed, Feb 19, 2020, 09:00 Owen Nichols  wrote:
> >> >
> >> > > Perhaps also worth considering: can we get WindowsStressNew added to
> >> the
> >> > PR
> >> > > checks?
> >> > >
> >> > > On Wed, Feb 19, 2020 at 8:50 AM Udo Kohlmeyer 
> wrote:
> >> > >
> >> > > > Is this something that can be fixed in a short time (2hrs)? If
> not,
> >> can
> >> > > > be revert and get back to a clean pipeline?
> >> > > >
> >> > > > --Udo
> >> > > >
> >> > > > On 2/19/20 8:23 AM, Jens Deppe wrote:
> >> > > > > Thanks Kirk,
> >> > > > >
> >> > > > > We're working on fixing this.
> >> > > > >
> >> > > > > --Jens
> >> > > > >
> >> > > > > On Tue, Feb 18, 2020 at 3:23 PM Kirk Lund 
> >> wrote:
> >> > > > >
> >> > > > >> I just started seeing the Redis PubSubTest fail in
> >> IntegrationTest
> >> > > after
> >> > > > >> rebasing on develop this afternoon. Looks like I have Jens'
> >> latest
> >> > > > commit
> >> > > > >> for this test:
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >> *commit 1befce17eaae2403828769840f86639e13fce81f
> (origin/develop,
> >> > > > >> origin/HEAD, develop)Author: Jens Deppe  >> > > > >> >Date:   Tue Feb 18 13:03:19 2020 -0800
> >> > > > GEODE-7798:
> >> > > > >> Fix flaky PubSub test (#4714)*
> >> > > > >>
> >> > > > >> *Authored-by: Jens Deppe  >> jde...@pivotal.io
> >> > >>>
> >> > > > Task
> >> > > > >> :geode-redis:integrationTest*
> >> > > > >>
> >> > > > >> Here's the stack traces:
> >> > > > >>
> >> > > > >> org.apache.geode.redis.PubSubTest > testPatternWithoutAGlob
> >> FAILED
> >> > > > >>  redis.clients.jedis.exceptions.JedisConnectionException:
> >> > > > >> java.net.SocketTimeoutException: Read timed out
> >> > > > >>  at
> >> > > > >>
> >> > > >
> >> >
> >>
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
> >> > > > >>  at
> >> > > > >>
> >> > redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
> >> > > > >>  at
> >> redis.clients.jedis.Protocol.process(Protocol.java:151)
> >> > > > >>  at
> redis.clients.jedis.Protocol.read(Protocol.java:215)
> >> > > > >>  at
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
> >> > > > >>  at
> >> > > > >>
> >> redis.clients.je

Re: Redis PubSubTest started failing

[Jens Deppe]

Thanks Kirk,

We're working on fixing this.

--Jens

On Tue, Feb 18, 2020 at 3:23 PM Kirk Lund  wrote:

> I just started seeing the Redis PubSubTest fail in IntegrationTest after
> rebasing on develop this afternoon. Looks like I have Jens' latest commit
> for this test:
>
>
>
>
>
>
>
> *commit 1befce17eaae2403828769840f86639e13fce81f (origin/develop,
> origin/HEAD, develop)Author: Jens Deppe  >Date:   Tue Feb 18 13:03:19 2020 -0800GEODE-7798:
> Fix flaky PubSub test (#4714)*
>
> *Authored-by: Jens Deppe >> Task
> :geode-redis:integrationTest*
>
> Here's the stack traces:
>
> org.apache.geode.redis.PubSubTest > testPatternWithoutAGlob FAILED
> redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
> at
> redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
> at redis.clients.jedis.Protocol.process(Protocol.java:151)
> at redis.clients.jedis.Protocol.read(Protocol.java:215)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
> at
> redis.clients.jedis.Connection.getIntegerReply(Connection.java:265)
> at redis.clients.jedis.Jedis.publish(Jedis.java:2690)
> at
> org.apache.geode.redis.PubSubTest.testPatternWithoutAGlob(PubSubTest.java:279)
>
> Caused by:
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:126)
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:196)
> ... 7 more
>
> org.apache.geode.redis.PubSubTest > testTwoSubscribersOneChannel FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 1
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at org.apache.geode.redis.PubSubTest.waitFor(PubSubTest.java:296)
> at
> org.apache.geode.redis.PubSubTest.testTwoSubscribersOneChannel(PubSubTest.java:140)
>
> org.apache.geode.redis.PubSubTest >
> testOneSubscriberSubscribingToTwoChannels FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 1
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at org.apache.geode.redis.PubSubTest.waitFor(PubSubTest.java:296)
> at
> org.apache.geode.redis.PubSubTest.testOneSubscriberSubscribingToTwoChannels(PubSubTest.java:110)
>
> org.apache.geode.redis.PubSubTest > testPatternAndRegularSubscribe FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 1
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at org.apache.geode.redis.PubSubTest.waitFor(PubSubTest.java:29

Re: Odg: acceptance test task failing?

[Jens Deppe]

The failing test is using a Postgres docker image as a backing store. I
think that something changed in this image requiring authentication when
making a connection. I think I have a fix for it currently running a PR:
https://github.com/apache/geode/pull/4712

--Jens

On Mon, Feb 17, 2020 at 8:09 AM Alberto Bustamante Reyes
 wrote:

> Last commits on develop:
>
> 9f8a2ff2b43c183b4824dd5ab764ecd2243cb2e1 GEODE-7800: Add Redis PSUBSCRIBE
> and PUNSUBSCRIBE commands (#4705)
> 1a0d9769e482f49e0c725c0d6adc75d324f88958 GEODE-7727: modify sender thread
> to detect release of connection (#4629)
> 5c6529a76dfad174be6a29438bf196013952b05b Geode 4263 (#4691)
> 8c40d5e66d1d8743f4b547de8cf429de8a187801 GEODE-7210: Fix
> RedundancyLevelPart1DUnitTest
> 5d2b1d1003982de248953230a8429f7ec19de692 GEODE-7791: fix
> MergeLogsDistributedTest (#4697)
>
> The first one that had a failed execution of acceptanceTest was
> GEODE-7800. In the PR it can be seen that acceptance test task started
> failing between commits ba04b6a and 9db6c17 .
>
>
> 
> De: Robert Houghton 
> Enviado: lunes, 17 de febrero de 2020 16:30
> Para: Mario Ivanac 
> Cc: dev@geode.apache.org 
> Asunto: Re: Odg: acceptance test task failing?
>
> I had only looked at develop, not the PR pipeline. More investigation is
> required.
>
> On Mon, Feb 17, 2020, 07:05 Mario Ivanac  wrote:
>
> > Hi,
> >
> > but this commit was merged to develop, on saturday morning, and test are
> > falling from friday.
> >
> > BR,
> > Mario
> > --
> > *Šalje:* Robert Houghton 
> > *Poslano:* 17. veljače 2020. 16:02
> > *Prima:* dev@geode.apache.org 
> > *Predmet:* Re: acceptance test task failing?
> >
> > The test has been erroring consistently on develop since
> >
> >
> https://github.com/apache/geode/commit/1a0d9769e482f49e0c725c0d6adc75d324f88958
> >
> > On Mon, Feb 17, 2020, 06:39 Alberto Bustamante Reyes
> >  wrote:
> >
> > > Hi,
> > >
> > > After just changing some typos on a PR, I got errors on
> > > geode-connectors:acceptanceTest task, but the tests were working fine
> > > before that change. I have seen that the acceptance test task in concur
> > has
> > > failed since last 14th February (15 executions since that day). and it
> > > seems all of them got the same error.
> > >
> > > Is there any problem with the task or the develop branch?
> > >
> > > Thanks,
> > >
> > > Alberto B.
> > >
> > >
> >
>

Re: Concourse tests logs

[Jens Deppe]

Hi Alberto,

You should be able to look at the 'archive_results' job and see links for
test artifacts at the bottom of the log. Something like this:


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0180/test-results/test/1578534134/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0180/test-artifacts/1578534134/windows-unittestfiles-OpenJDK8-1.12.0-SNAPSHOT.0180.tgz

--Jens

On Thu, Jan 9, 2020 at 9:32 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> How could I check the tests reports from concourse executions? I see some
> tests failing on a PR but they work fine on my laptop, so I would like to
> have more info to fix them.
>
> Thanks!
>
> Alberto B.
>

Re: RFC - Logging to Standard Out

[Jens Deppe]

+1 Why didn't we do this ages ago? :)

On Wed, Jan 8, 2020 at 12:39 PM Jacob Barrett  wrote:

> Please see RFC for Logging to Standard Out.
>
> https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
>  >
>
> Please comment by 1/21/2020.
>
> Thanks,
> Jake
>
>

[ANNOUNCE] Aaron Lindsey as newest Geode committer

[Jens Deppe]

Apologies for sending this out late...

On behalf of the Apache Geode PMC, I'm pleased to announce that Aaron has
accepted his invitation to join the Geode project as committer.

Welcome Aaron!!

--Jens

Re: [DISCUSS] `status locator` command fail when locator's ssl is turned on

[Jens Deppe]

I think Jinmei is also referring to the situation where you might *not* already
be connected but want to execute something like this:

gfsh>status locator --host=fooish --port=10334


In this case it would fail as well. Seems like we'd either need to remove
those options so you *always* need to 'connect' if you want to access a
remote system, or we need to add an *optional* --security-properties-file
option that would only be necessary if the shell isn't already connected.

--Jens




On Fri, Dec 20, 2019 at 3:15 PM Ernest Burghardt 
wrote:

> I like the approach Jens is suggesting, seems intuitive to me
>
> On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe  wrote:
>
> > So it seems that the situation is something like this where I'm able to
> > make the initial connection but then retrieving status fails:
> >
> > gfsh>connect --security-properties-file=../security.properties
> >
> > gfsh>status locator --name=locator1
> > Server version response invalid: This could be the result of trying to
> > connect a non-SSL-enabled client to an SSL-enabled locator.
> >
> >
> > It would seem very weird if I have to provide additional connection
> params
> > to the 'status' command if I've already provided them as part of the
> > 'connect'. Could we not stash the connection properties (in the Gfsh
> > instance object) for subsequent usage?
> >
> > --Jens
> >
> > On Wed, Dec 18, 2019 at 9:04 AM Jinmei Liao  wrote:
> >
> > > "status locator" command is broken on ssl enabled locators ever since
> we
> > > fixed a bug that leaked the connection properties from one tcp socket
> > > connection to another. Before that it would just magically work if we
> > have
> > > previously made a successfully tcp connection to that same locator, now
> > we
> > > are either required to find a way to specify the ssl properties when
> > > running the `status locator` command or change what we want to report
> > back
> > > to the user.
> > >
> > > Here is what's happening now when we issue the command:
> > >
> > >1. it needs to retrieve two sets of info from locator: general info
> > like
> > >(pid, working dir, status, jvm args etc) and whether cluster
> > > configuration
> > >service is running or not.
> > >2. when locator’s ssl is on, the retrieval of the cluster
> > configuration
> > >info will always fail since it’s using a tcp connection to get that
> > info
> > >and we currently don’t have the ssl security properties to connect.
> > >3. when locator’s ssl is on, the retrieval of the general info will
> > >mostly succeed except when user is only providing a host and port,
> > > there we
> > >would also need the ssl security properties in order to create an
> ssl
> > >socket.
> > >
> > >
> > > So we wither need to add an option for user to specify a
> > > `--security-properties-file` option to include all the ssl connection
> > > properties or change the behavior not to report cluster config status
> or
> > > not allowing host/port combination. (I am not here long enough to
> > > understand what users would use this command for, so this is just a
> > random
> > > suggestions).
> > >
> > > Comments/thoughts?
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: [DISCUSS] `status locator` command fail when locator's ssl is turned on

[Jens Deppe]

So it seems that the situation is something like this where I'm able to
make the initial connection but then retrieving status fails:

gfsh>connect --security-properties-file=../security.properties

gfsh>status locator --name=locator1
Server version response invalid: This could be the result of trying to
connect a non-SSL-enabled client to an SSL-enabled locator.


It would seem very weird if I have to provide additional connection params
to the 'status' command if I've already provided them as part of the
'connect'. Could we not stash the connection properties (in the Gfsh
instance object) for subsequent usage?

--Jens

On Wed, Dec 18, 2019 at 9:04 AM Jinmei Liao  wrote:

> "status locator" command is broken on ssl enabled locators ever since we
> fixed a bug that leaked the connection properties from one tcp socket
> connection to another. Before that it would just magically work if we have
> previously made a successfully tcp connection to that same locator, now we
> are either required to find a way to specify the ssl properties when
> running the `status locator` command or change what we want to report back
> to the user.
>
> Here is what's happening now when we issue the command:
>
>1. it needs to retrieve two sets of info from locator: general info like
>(pid, working dir, status, jvm args etc) and whether cluster
> configuration
>service is running or not.
>2. when locator’s ssl is on, the retrieval of the cluster configuration
>info will always fail since it’s using a tcp connection to get that info
>and we currently don’t have the ssl security properties to connect.
>3. when locator’s ssl is on, the retrieval of the general info will
>mostly succeed except when user is only providing a host and port,
> there we
>would also need the ssl security properties in order to create an ssl
>socket.
>
>
> So we wither need to add an option for user to specify a
> `--security-properties-file` option to include all the ssl connection
> properties or change the behavior not to report cluster config status or
> not allowing host/port combination. (I am not here long enough to
> understand what users would use this command for, so this is just a random
> suggestions).
>
> Comments/thoughts?
>
> --
> Cheers
>
> Jinmei
>

Re: Odg: Proposal of new config property "ssl-server-name-extension"

[Jens Deppe]

Hi Mario,

I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.


> Jens Deppe 
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
>   SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
>
Thanks!
--Jens

On Mon, Dec 9, 2019 at 2:37 AM Mario Ivanac  wrote:

> Hi,
>
> Since this proposal is open for almost three weeks,
> and we have 2 plus one,
>
> We will continue with proposed solution.
>
> Regards,
> Mario
>
> 
> Šalje: Mario Ivanac 
> Poslano: 19. studenog 2019. 12:26
> Prima: dev@geode.apache.org 
> Predmet: Proposal of new config property "ssl-server-name-extension"
>
> Hi geode dev,
>
> as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414
> we would like to introduce new config property "ssl-server-name-extension".
>
> This property will contain generic string, which will be added as Server
> Name Indication (SNI) parameter to Client Hello message.
>
> Do you agree with this proposal?
>
> Thanks,
> Mario
>

Re: New geode-gfsh module

[Jens Deppe]

Just to be clear, this effort does *not* result in a standalone gfsh
executable/jar.

Sorry.

--Jens

On Fri, Dec 6, 2019 at 6:27 AM Jens Deppe  wrote:

> We have completed the work to move the gfsh code into a separate gradle
> submodule. This work has the following implications and effects:
>
>- geode-core does not have any direct dependencies on Spring libraries
>anymore
>- Anyone building with Geode will need to include the '*geode-gfsh'*
>dependency in order to use gfsh commands. This is relevant to anyone using
>Spring Boot (or Spring Data Geode) to launch locators or servers.
>- The Geode distribution (*.zip/.tgz) still includes all necessary
>libs required to use gfsh (i.e. Spring libraries)
>- There is no change for users using the 'gfsh' utility directly to
>launch locators and servers since the *gfsh-dependencies.jar* still
>contains all necessary references to Spring, etc.
>
> Please let us know if you discover any issues related to this work.
>
> Thanks
> -- Jens & Patrick
>

Re: New geode-gfsh module

[Jens Deppe]

The geode-dependencies.jar now includes the *geode-gfsh.jar* (as well as
Spring still).

--Jens

On Fri, Dec 6, 2019 at 8:49 AM Anthony Baker  wrote:

> Did the class path in geode-dependencies.jar change?  If so, that might
> also affect applications that relied on the those (spring) jars being
> available on the class path.  Of course, they can fix that by explicitly
> injecting the applications dependencies into the class path as needed.
>
> Anthony
>
>
> > On Dec 6, 2019, at 6:27 AM, Jens Deppe  wrote:
> >
> > We have completed the work to move the gfsh code into a separate gradle
> > submodule. This work has the following implications and effects:
> >
> >   - geode-core does not have any direct dependencies on Spring libraries
> >   anymore
> >   - Anyone building with Geode will need to include the '*geode-gfsh'*
> >   dependency in order to use gfsh commands. This is relevant to anyone
> using
> >   Spring Boot (or Spring Data Geode) to launch locators or servers.
> >   - The Geode distribution (*.zip/.tgz) still includes all necessary libs
> >   required to use gfsh (i.e. Spring libraries)
> >   - There is no change for users using the 'gfsh' utility directly to
> >   launch locators and servers since the *gfsh-dependencies.jar* still
> >   contains all necessary references to Spring, etc.
> >
> > Please let us know if you discover any issues related to this work.
> >
> > Thanks
> > -- Jens & Patrick
>
>

Re: Odg: Certificate Based Authorization

[Jens Deppe]

Thanks for the write-up. I think it does require a bit of clarification
around how the functionality is enabled.

You've stated:

For client connections, we could presume that certificate based
> authorization should be used if both features are enabled, but the client
> cache properties don’t provide credentials
> (security-username/security-password).


Currently, the presence of any '*auth-init' parameters, does not
necessarily require setting *security-username/password* (although almost
all implementations of AuthInitialize probably do use them). So this
condition will not be sufficient to enable this new functionality.

Although we already have so many parameters I think that having an explicit
parameter, to enable this feature, will avoid any possible confusion.

I'm wondering whether, for an initial deliverable, we should require
*ssl-enabled-components=all*. This would not allow a mix of different forms
of authentication for different endpoints. Perhaps this might simplify the
implementation but would not preclude us from adding that capability in the
future.

--Jens

On Fri, Dec 6, 2019 at 1:13 AM Mario Kevo  wrote:

> Hi all,
>
> I wrote up a proposal for Certificate Based Authorization.
> Please review and comment on the below proposal.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Certificate+Based+Authorization
>
> BR,
> Mario
> 
> Šalje: Udo Kohlmeyer 
> Poslano: 2. prosinca 2019. 20:10
> Prima: dev@geode.apache.org 
> Predmet: Re: Certificate Based Authorization
>
> +1
>
> On 12/2/19 1:29 AM, Mario Kevo wrote:
> > Hi,
> >
> >
> >
> > There is another potential functionality we would like to discuss and
> get some comments for. The idea is TLS certificate based authorization.
> Currently, if a user wants secure communication (TLS) + authorization, he
> needs to enable TLS and access control. The user also needs to handle both
> the certificates for TLS and the credentials for access control. The idea
> we have is to use both features: TLS and access control, but remove the
> need to handle the credentials (generating and securely storing the
> username and password). Instead of the credentials, the certificate subject
> DN would be used for authorization.
> >
> >
> >
> > This would of course be optional. We would leave the possibility to use
> these 2 features as they are right now, but would also provide a
> configuration option to use the features without the need for client
> credentials, utilizing the certificate information instead.
> >
> >
> >
> > For further clarity, here are the descriptions of how the options would
> work:
> >
> >
> >
> >1.  Using TLS and access control as they work right now
> >   *   Certificates are prepared for TLS
> >   *   A SecurityManager is prepared for access control
> authentication/authorization. As part of this, a file (e.g. security.json)
> is prepared where we define the allowed usernames, passwords and
> authorization rights for each username
> >   *   The credentials are distributed towards clients. Here a user
> needs to consider secure distribution and periodical rotation of
> credentials.
> >
> > Once a client initiates a connection, we first get the TLS layer and
> certificate check, and right after that we perform the
> authentication/authorization of the user credentials.
> >
> >
> >
> >1.  TLS certificate based authorization
> >   *   Certificates are prepared for TLS
> >   *   A SecurityManager is prepared for access control
> authentication/authorization. As part of this, a file (e.g. security.json)
> is prepared. In this case we don’t define the authorization rights based on
> usernames/passwords but based on certificate subject DNs.
> >   *   There is no more need to distribute or periodically rotate the
> credentials, since there would be none. Authorization would be based  on
> the subject DN fetched from the certificate used for that same connection
> >
> > Once a client initiates a connection, and when we get past the TLS
> layer, at the moment where geode expects the credentials from the client
> connection, we just take the certificate subject DN instead and provide it
> to the security manager for authorization.
> >
> >
> >
> > This wouldn’t lower the level of security (we can have TLS enabled
> without access control already), but would provide authentication without
> the hassle of username and password handling.
> >
> >
> >
> > This is the basic description of the idea. There would be more things to
> consider, like multi user authentication, but for now we would just like to
> get some initial feedback. If it is considered useful, we could get into
> the details.
> >
> >
> > BR,
> >
> > Mario
> >
> >
>

Re: New geode-gfsh module

[Jens Deppe]

Apologies to anyone who has any gfsh related PRs in flight as it will
require rebasing onto develop.

--Jens

On Fri, Dec 6, 2019 at 6:27 AM Jens Deppe  wrote:

> We have completed the work to move the gfsh code into a separate gradle
> submodule. This work has the following implications and effects:
>
>- geode-core does not have any direct dependencies on Spring libraries
>anymore
>- Anyone building with Geode will need to include the '*geode-gfsh'*
>dependency in order to use gfsh commands. This is relevant to anyone using
>Spring Boot (or Spring Data Geode) to launch locators or servers.
>- The Geode distribution (*.zip/.tgz) still includes all necessary
>libs required to use gfsh (i.e. Spring libraries)
>- There is no change for users using the 'gfsh' utility directly to
>launch locators and servers since the *gfsh-dependencies.jar* still
>contains all necessary references to Spring, etc.
>
> Please let us know if you discover any issues related to this work.
>
> Thanks
> -- Jens & Patrick
>

New geode-gfsh module

[Jens Deppe]

We have completed the work to move the gfsh code into a separate gradle
submodule. This work has the following implications and effects:

   - geode-core does not have any direct dependencies on Spring libraries
   anymore
   - Anyone building with Geode will need to include the '*geode-gfsh'*
   dependency in order to use gfsh commands. This is relevant to anyone using
   Spring Boot (or Spring Data Geode) to launch locators or servers.
   - The Geode distribution (*.zip/.tgz) still includes all necessary libs
   required to use gfsh (i.e. Spring libraries)
   - There is no change for users using the 'gfsh' utility directly to
   launch locators and servers since the *gfsh-dependencies.jar* still
   contains all necessary references to Spring, etc.

Please let us know if you discover any issues related to this work.

Thanks
-- Jens & Patrick

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

[Jens Deppe]

Thanks for the positive feedback. This proposal is accepted and development
will proceed.

--Jens

On Mon, Nov 25, 2019 at 9:27 AM Dale Emery  wrote:

> +ힹ
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
> > On Nov 22, 2019, at 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: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

For the purpose of moving this forward, I have merged PR #4311 [1]. From a
runtime POV this now requires a minimum 3.0 servlet compatible container.
Documented minimum, however, is at least 3.1.

I suggest that if anyone would like to see documented newer support that
that should be proposed separately.

Thanks
--Jens

[1] - https://github.com/apache/geode/pull/4311

On Wed, Nov 20, 2019 at 10:15 AM Jens Deppe  wrote:

> To be clear, this proposal just wants to update the *minimum* *documented*
> requirement. The following PR would require that to be 3.0:
> https://github.com/apache/geode/pull/4311
>
> There is no additional change required other than documentation.
>
> --Jens
>
> On Wed, Nov 20, 2019 at 9:46 AM Udo Kohlmeyer  wrote:
>
>> I think that we should really be looking at going to 4.0.
>>
>> It would be compatible with 3.1, but given that 4.0 is standard with
>> Java 8 (which already EOL), we should try and get onto the latest.
>>
>> I don't think that us aligning ourselves with a tech release in 2013 is
>> something we should do.
>>
>> --Udo
>>
>> On 11/20/19 9:17 AM, Jens Deppe wrote:
>> > Since there appears to be consensus, I'm going to give this thread
>> another
>> > 24 hours and will then consider this proposal accepted.
>> >
>> > If anyone does have concerns please do raise them now.
>> >
>> > Thanks
>> > --Jens
>> >
>> > On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior 
>> wrote:
>> >
>> >> +1 for bumping to 3.1
>> >>
>> >> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett 
>> >> wrote:
>> >>
>> >>> +1 for 3.1
>> >>>
>> >>>> On Nov 15, 2019, at 3:08 PM, Jens Deppe  wrote:
>> >>>>
>> >>>> +1 to bumping the documented support to 3.1.
>> >>>>
>> >>>> The prompting for this proposal is due to this PR which specifically
>> >>> wants
>> >>>> to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
>> >>>>
>> >>>> Thus implementing this change will not preclude being able to use the
>> >>>> Session Module in a 3.0 container (even if we document support as
>> being
>> >>>> against 3.1)
>> >>>>
>> >>>> --Jens
>> >>>>
>> >>>>> On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:
>> >>>>>
>> >>>>> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1
>> open
>> >>> up
>> >>>>> more doors (e.g. NIO), but is also implemented by all current
>> Servlet
>> >>>>> Container providers (Tomcat, Jetty, etc).  Additionally, given all
>> the
>> >>>>> Servlet Containers Jens mentioned at the version that started
>> >> supporting
>> >>>>> Servlet 3.0 are no longer supported, then 3.1 seems like a
>> >>> good/reasonable
>> >>>>> target.
>> >>>>>
>> >>>>> -j
>> >>>>>
>> >>>>>> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith 
>> >> wrote:
>> >>>>>> +1 to bumping to servlet 3.0.
>> >>>>>>
>> >>>>>> -Dan
>> >>>>>>
>> >>>>>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith <
>> smith...@macewan.ca>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Seems to me as long as newer Servlet specs do not deprecate
>> >>>>>>> functionality/api that the session module requires AND that the
>> >>> session
>> >>>>>>> module is not missing any important functionality provided by
>> newer
>> >>>>>> Servlet
>> >>>>>>> specs that it's best to base support the oldest Servlet spec that
>> is
>> >>>>>> still
>> >>>>>>> supported by active container versions. As Jens nicely enumerated,
>> >>> this
>> >>>>>>> seems to be Servlet 3.0 right now.
>> >>>>>>>
>> >>>>>>> At least that's the approach that would give the session
>> management
>> >>>>>>> modules the widest audience. I am currently writing a Servlet 4.0
>> >> web
>> >>>>> app
>> &g

Re: Certificate Based Authorization

[Jens Deppe]

Hi Mario,

Definitely sounds like a good idea! Feel free to write up a RFC proposal
with more details.

Thanks
--Jens

On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo  wrote:

> Hi,
>
>
>
> There is another potential functionality we would like to discuss and get
> some comments for. The idea is TLS certificate based authorization.
> Currently, if a user wants secure communication (TLS) + authorization, he
> needs to enable TLS and access control. The user also needs to handle both
> the certificates for TLS and the credentials for access control. The idea
> we have is to use both features: TLS and access control, but remove the
> need to handle the credentials (generating and securely storing the
> username and password). Instead of the credentials, the certificate subject
> DN would be used for authorization.
>
>
>
> This would of course be optional. We would leave the possibility to use
> these 2 features as they are right now, but would also provide a
> configuration option to use the features without the need for client
> credentials, utilizing the certificate information instead.
>
>
>
> For further clarity, here are the descriptions of how the options would
> work:
>
>
>
>   1.  Using TLS and access control as they work right now
>  *   Certificates are prepared for TLS
>  *   A SecurityManager is prepared for access control
> authentication/authorization. As part of this, a file (e.g. security.json)
> is prepared where we define the allowed usernames, passwords and
> authorization rights for each username
>  *   The credentials are distributed towards clients. Here a user
> needs to consider secure distribution and periodical rotation of
> credentials.
>
> Once a client initiates a connection, we first get the TLS layer and
> certificate check, and right after that we perform the
> authentication/authorization of the user credentials.
>
>
>
>   1.  TLS certificate based authorization
>  *   Certificates are prepared for TLS
>  *   A SecurityManager is prepared for access control
> authentication/authorization. As part of this, a file (e.g. security.json)
> is prepared. In this case we don’t define the authorization rights based on
> usernames/passwords but based on certificate subject DNs.
>  *   There is no more need to distribute or periodically rotate the
> credentials, since there would be none. Authorization would be based  on
> the subject DN fetched from the certificate used for that same connection
>
> Once a client initiates a connection, and when we get past the TLS layer,
> at the moment where geode expects the credentials from the client
> connection, we just take the certificate subject DN instead and provide it
> to the security manager for authorization.
>
>
>
> This wouldn’t lower the level of security (we can have TLS enabled without
> access control already), but would provide authentication without the
> hassle of username and password handling.
>
>
>
> This is the basic description of the idea. There would be more things to
> consider, like multi user authentication, but for now we would just like to
> get some initial feedback. If it is considered useful, we could get into
> the details.
>
>
> BR,
>
> Mario
>
>

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
>

[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: Proposal of new config property "ssl-server-name-extension"

[Jens Deppe]

This thread contains more background on the reasons for this proposal:
https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E

On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin  wrote:

> I've reviewed the PR and I believe I understand the use case, but I feel a
> bit uncomfortable with the misuse of SNI. As I understand it, and as it has
> been already mentioned, SNI is used to determine which SSL certificate
> should be presented to a client.
>
> I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> and that a new client property should be used instead. That is, a different
> property, unrelated to SSL, should be used to set what will be verified
> against CLIENT_HELLO_EXTENSION.
>
> On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe  wrote:
>
> > I'd like to add my comment from the original PR here again:
> >
> >
> > Although I support the particular use case, I would prefer the
> > implementation being a bit more abstracted. Specifically, if we provided
> an
> > extension point which would allow modification of SSLParameters then we
> > wouldn't be coupling to a particular use case. So I'm thinking that the
> > user would define (via say a ssl-parameter-extension parameter) a class
> > that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> > this use-case and does what it needs. The user class would need to
> > implement an interface something like this:
> >
> > public interface SSLParameterExtension {
> >   SSLParameter modify(SSLParameter, SSLConfig);
> > }
> >
> > I would imagine seeing the user implementation of this being attached to
> > SSLConfig.
> >
> >
> > (https://github.com/apache/geode/pull/4310)
> >
> > I don't mind (mis)using the Server Name field to convey some other
> > information, but since it's possible to abstract the specific nature and
> > application of that information, I think we should do so. Anyone else who
> > looks at the code is going to wonder what the use is especially if the
> > consumer of that particular piece of info is going to be provided via an
> > external SSLEngine implementation.
> >
> > --Jens
> >
> > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith  wrote:
> >
> > > Can you clarify which connections will use this
> ssl-server-name-extension
> > > as part of the Client Hello? client to locator, client to server,
> server
> > to
> > > server, WAN site to WAN site, ... all of the above?
> > >
> > > I'm fine with adding the new property.
> > >
> > > At some point, I think we need to think about making it easier to plug
> in
> > > custom logic to control the entire socket creation and TLS handshake. I
> > > think technically you can take over the whole process if you set the
> > > ssl-use-default-context property and then configure the default
> > SSLContext
> > > for your entire process, but that is not ideal.
> > >
> > > -Dan
> > >
> > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black 
> wrote:
> > >
> > > > I have read the e-mail and the ticket I am not sure how this field is
> > > going
> > > > to be used.   Maybe you can expand on the intent of this field.
> > > >
> > > > From the property "ssl-server-name-extension" it feels like we are
> > > > intending to correlate with something presented in the SSL
> certificate.
> > > > It would be great if that was explained plainly for the reader in
> more
> > > > detail.
> > > >
> > > > For now I can only -1.
> > > >
> > > > Charlie
> > > >
> > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac 
> > > > wrote:
> > > >
> > > > > Hi geode dev,
> > > > >
> > > > > as a part of solution for
> > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > we would like to introduce new config property
> > > > "ssl-server-name-extension".
> > > > >
> > > > > This property will contain generic string, which will be added as
> > > Server
> > > > > Name Indication (SNI) parameter to Client Hello message.
> > > > >
> > > > > Do you agree with this proposal?
> > > > >
> > > > > Thanks,
> > > > > Mario
> > > > >
> > > >
> > > >
> > > > --
> > > > Charlie Black | cbl...@pivotal.io
> > > >
> > >
> >
>

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

To be clear, this proposal just wants to update the *minimum* *documented*
requirement. The following PR would require that to be 3.0:
https://github.com/apache/geode/pull/4311

There is no additional change required other than documentation.

--Jens

On Wed, Nov 20, 2019 at 9:46 AM Udo Kohlmeyer  wrote:

> I think that we should really be looking at going to 4.0.
>
> It would be compatible with 3.1, but given that 4.0 is standard with
> Java 8 (which already EOL), we should try and get onto the latest.
>
> I don't think that us aligning ourselves with a tech release in 2013 is
> something we should do.
>
> --Udo
>
> On 11/20/19 9:17 AM, Jens Deppe wrote:
> > Since there appears to be consensus, I'm going to give this thread
> another
> > 24 hours and will then consider this proposal accepted.
> >
> > If anyone does have concerns please do raise them now.
> >
> > Thanks
> > --Jens
> >
> > On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior 
> wrote:
> >
> >> +1 for bumping to 3.1
> >>
> >> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett 
> >> wrote:
> >>
> >>> +1 for 3.1
> >>>
> >>>> On Nov 15, 2019, at 3:08 PM, Jens Deppe  wrote:
> >>>>
> >>>> +1 to bumping the documented support to 3.1.
> >>>>
> >>>> The prompting for this proposal is due to this PR which specifically
> >>> wants
> >>>> to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
> >>>>
> >>>> Thus implementing this change will not preclude being able to use the
> >>>> Session Module in a 3.0 container (even if we document support as
> being
> >>>> against 3.1)
> >>>>
> >>>> --Jens
> >>>>
> >>>>> On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:
> >>>>>
> >>>>> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1
> open
> >>> up
> >>>>> more doors (e.g. NIO), but is also implemented by all current Servlet
> >>>>> Container providers (Tomcat, Jetty, etc).  Additionally, given all
> the
> >>>>> Servlet Containers Jens mentioned at the version that started
> >> supporting
> >>>>> Servlet 3.0 are no longer supported, then 3.1 seems like a
> >>> good/reasonable
> >>>>> target.
> >>>>>
> >>>>> -j
> >>>>>
> >>>>>> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith 
> >> wrote:
> >>>>>> +1 to bumping to servlet 3.0.
> >>>>>>
> >>>>>> -Dan
> >>>>>>
> >>>>>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith  >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Seems to me as long as newer Servlet specs do not deprecate
> >>>>>>> functionality/api that the session module requires AND that the
> >>> session
> >>>>>>> module is not missing any important functionality provided by newer
> >>>>>> Servlet
> >>>>>>> specs that it's best to base support the oldest Servlet spec that
> is
> >>>>>> still
> >>>>>>> supported by active container versions. As Jens nicely enumerated,
> >>> this
> >>>>>>> seems to be Servlet 3.0 right now.
> >>>>>>>
> >>>>>>> At least that's the approach that would give the session management
> >>>>>>> modules the widest audience. I am currently writing a Servlet 4.0
> >> web
> >>>>> app
> >>>>>>> and the Geode session module is working great except that I need to
> >>>>> layer
> >>>>>>> on an additional filter to ensure my session cookies are secure.
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Charles Smith
> >>>>>>>
> >>>>>>> Developer/Analyst
> >>>>>>>
> >>>>>>> Web Architecture and Development
> >>>>>>> MacEwan University
> >>>>>>> smith...@macewan.ca
> >>>>>>>
> >>>>>>>
> >>>>>>> 
> >>>>>>> F

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

Since there appears to be consensus, I'm going to give this thread another
24 hours and will then consider this proposal accepted.

If anyone does have concerns please do raise them now.

Thanks
--Jens

On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior  wrote:

> +1 for bumping to 3.1
>
> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett 
> wrote:
>
> > +1 for 3.1
> >
> > > On Nov 15, 2019, at 3:08 PM, Jens Deppe  wrote:
> > >
> > > +1 to bumping the documented support to 3.1.
> > >
> > > The prompting for this proposal is due to this PR which specifically
> > wants
> > > to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
> > >
> > > Thus implementing this change will not preclude being able to use the
> > > Session Module in a 3.0 container (even if we document support as being
> > > against 3.1)
> > >
> > > --Jens
> > >
> > >> On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:
> > >>
> > >> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open
> > up
> > >> more doors (e.g. NIO), but is also implemented by all current Servlet
> > >> Container providers (Tomcat, Jetty, etc).  Additionally, given all the
> > >> Servlet Containers Jens mentioned at the version that started
> supporting
> > >> Servlet 3.0 are no longer supported, then 3.1 seems like a
> > good/reasonable
> > >> target.
> > >>
> > >> -j
> > >>
> > >>> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith 
> wrote:
> > >>>
> > >>> +1 to bumping to servlet 3.0.
> > >>>
> > >>> -Dan
> > >>>
> > >>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
> > >>> wrote:
> > >>>
> > >>>> Seems to me as long as newer Servlet specs do not deprecate
> > >>>> functionality/api that the session module requires AND that the
> > session
> > >>>> module is not missing any important functionality provided by newer
> > >>> Servlet
> > >>>> specs that it's best to base support the oldest Servlet spec that is
> > >>> still
> > >>>> supported by active container versions. As Jens nicely enumerated,
> > this
> > >>>> seems to be Servlet 3.0 right now.
> > >>>>
> > >>>> At least that's the approach that would give the session management
> > >>>> modules the widest audience. I am currently writing a Servlet 4.0
> web
> > >> app
> > >>>> and the Geode session module is working great except that I need to
> > >> layer
> > >>>> on an additional filter to ensure my session cookies are secure.
> > >>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>> Charles Smith
> > >>>>
> > >>>> Developer/Analyst
> > >>>>
> > >>>> Web Architecture and Development
> > >>>> MacEwan University
> > >>>> smith...@macewan.ca
> > >>>>
> > >>>>
> > >>>> 
> > >>>> From: John Blum 
> > >>>> Sent: Friday, November 15, 2019 11:17 AM
> > >>>> To: geode 
> > >>>> Subject: Re: Proposal to modify Servlet spec support for the HTTP
> > >> Session
> > >>>> Management Module for AppServers
> > >>>>
> > >>>> Since the Servlet 3.1 spec is available and the current version is
> > 4.0,
> > >>> why
> > >>>> not consider 3.1 or even 4.0, actually?
> > >>>>
> > >>>> -j
> > >>>>
> > >>>> On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe 
> wrote:
> > >>>>
> > >>>>> Hello Charles; thanks very much for bringing this up.
> > >>>>>
> > >>>>> I vote +1 on this proposal.
> > >>>>>
> > >>>>> Just to add a bit more details for others:
> > >>>>>
> > >>>>> The 3.0 Servlet Spec was finalized at the end of 2009. The
> *earliest*
> > >>>>> versions of various containers that supported it are:
> > >>>>>
> > >>>>>   - Jetty 8 (EOL'd since 11/2014) [1]
> > >>>>>  

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

+1 to bumping the documented support to 3.1.

The prompting for this proposal is due to this PR which specifically wants
to utilize a *3.0* API: https://github.com/apache/geode/pull/4311

Thus implementing this change will not preclude being able to use the
Session Module in a 3.0 container (even if we document support as being
against 3.1)

--Jens

On Fri, Nov 15, 2019 at 2:57 PM John Blum  wrote:

> I would minimally bump it to 3.1 then.  Not only does Servlet 3.1 open up
> more doors (e.g. NIO), but is also implemented by all current Servlet
> Container providers (Tomcat, Jetty, etc).  Additionally, given all the
> Servlet Containers Jens mentioned at the version that started supporting
> Servlet 3.0 are no longer supported, then 3.1 seems like a good/reasonable
> target.
>
> -j
>
> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith  wrote:
>
> > +1 to bumping to servlet 3.0.
> >
> > -Dan
> >
> > On Fri, Nov 15, 2019 at 12:16 PM Charles Smith 
> > wrote:
> >
> > > Seems to me as long as newer Servlet specs do not deprecate
> > > functionality/api that the session module requires AND that the session
> > > module is not missing any important functionality provided by newer
> > Servlet
> > > specs that it's best to base support the oldest Servlet spec that is
> > still
> > > supported by active container versions. As Jens nicely enumerated, this
> > > seems to be Servlet 3.0 right now.
> > >
> > > At least that's the approach that would give the session management
> > > modules the widest audience. I am currently writing a Servlet 4.0 web
> app
> > > and the Geode session module is working great except that I need to
> layer
> > > on an additional filter to ensure my session cookies are secure.
> > >
> > >
> > > --
> > >
> > > Charles Smith
> > >
> > > Developer/Analyst
> > >
> > > Web Architecture and Development
> > > MacEwan University
> > > smith...@macewan.ca
> > >
> > >
> > > 
> > > From: John Blum 
> > > Sent: Friday, November 15, 2019 11:17 AM
> > > To: geode 
> > > Subject: Re: Proposal to modify Servlet spec support for the HTTP
> Session
> > > Management Module for AppServers
> > >
> > > Since the Servlet 3.1 spec is available and the current version is 4.0,
> > why
> > > not consider 3.1 or even 4.0, actually?
> > >
> > > -j
> > >
> > > On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe  wrote:
> > >
> > > > Hello Charles; thanks very much for bringing this up.
> > > >
> > > > I vote +1 on this proposal.
> > > >
> > > > Just to add a bit more details for others:
> > > >
> > > > The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
> > > > versions of various containers that supported it are:
> > > >
> > > >- Jetty 8 (EOL'd since 11/2014) [1]
> > > >- Tomcat 7 (Version 6 EOL'd 2017) [2]
> > > >- JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017)
> > [3]
> > > >- Websphere 8.0 (End of support 4/2018) [4]
> > > >- Weblogic 12cR1 (Extended Support until 12/2019) [5]
> > > >
> > > > The implication is that, of these products, there are *no* currently
> > > > supported versions that *do not* support the Servlet 3.0 spec. I
> > believe
> > > it
> > > > is quite safe for us to indicate that the Session Modules are now
> only
> > > > supported on 3.0 compliant containers.
> > > >
> > > > --Jens
> > > >
> > > > [1] -
> > > >
> > >
> >
> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
> > > > [2] - http://tomcat.apache.org/whichversion.html
> > > > [3] - https://access.redhat.com/support/policy/updates/jboss_notes
> > > > [4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
> > > > [5] -
> > > >
> > > >
> > >
> >
> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
> > > >
> > > > On Fri, Nov 15, 2019 at 8:11 AM Charles Smith 
> > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > The Geode HTTP Session Management Module for AppServers currently
> > > states:
> > > > > This approach is a generic solut

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

[Jens Deppe]

Hello Charles; thanks very much for bringing this up.

I vote +1 on this proposal.

Just to add a bit more details for others:

The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
versions of various containers that supported it are:

   - Jetty 8 (EOL'd since 11/2014) [1]
   - Tomcat 7 (Version 6 EOL'd 2017) [2]
   - JBoss Web 3.0.0 (version 2.x reached End of Maintenance 11/2017) [3]
   - Websphere 8.0 (End of support 4/2018) [4]
   - Weblogic 12cR1 (Extended Support until 12/2019) [5]

The implication is that, of these products, there are *no* currently
supported versions that *do not* support the Servlet 3.0 spec. I believe it
is quite safe for us to indicate that the Session Modules are now only
supported on 3.0 compliant containers.

--Jens

[1] -
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
[2] - http://tomcat.apache.org/whichversion.html
[3] - https://access.redhat.com/support/policy/updates/jboss_notes
[4] - https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
[5] -
https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life

On Fri, Nov 15, 2019 at 8:11 AM Charles Smith  wrote:

> Hello,
>
> The Geode HTTP Session Management Module for AppServers currently states:
> This approach is a generic solution, which is supported by any container
> that implements the Servlet 2.4 specification.
> I would like to suggest that this official support be bumped up to the
> Servlet 3.0 specification.
>
> There are some important cookie security features missing in the ancient
> Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping support to
> Servlet 3.0 would allow the Geode AppServer session module to inherently
> support these session cookie security features.
>
> I have logged the following Jira issue:
>
> https://issues.apache.org/jira/browse/GEODE-7438
>
> and submitted a pull request that provides the necessary support if the
> Geode community agrees this is a good idea.
>
> And thank you for the excellent Apache Geode project!
>
> --
>
> Charles Smith
>
> Developer/Analyst
>
> Web Architecture and Development
> MacEwan University
> smith...@macewan.ca
>
>

Re: Adding GEODE-7412 to 1.11 release

[Jens Deppe]

Hmm, I thought this was implicitly fixed by various build refactorings that
went into 1.11.0. I see that we're creating local maven artifacts for
geode-pulse-1.11.0.war. The next question is then whether we're actually
publishing those.

--Jens

On Fri, Nov 8, 2019 at 12:56 PM Owen Nichols  wrote:

> +1
>
> > On Nov 8, 2019, at 12:54 PM, Udo Kohlmeyer  wrote:
> >
> > @Owen,
> >
> > I did not specifically check all web archives for this issue. Yes, I
> *should* have been caught in that ticket.
> >
> > On 11/8/19 11:03 AM, Owen Nichols wrote:
> >> I’m curious, how was this missed in
> https://issues.apache.org/jira/browse/GEODE-7241 <
> https://issues.apache.org/jira/browse/GEODE-7241> ?
> >>
> >>> On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer  wrote:
> >>>
> >>> Hi there Geode Dev,
> >>>
> >>> I would like to request that we add
> https://issues.apache.org/jira/browse/GEODE-7412 <
> https://issues.apache.org/jira/browse/GEODE-7412> to the 1.11 release.
> >>>
> >>> This change is a build change that has crept in since 1.8. The issue
> that is to be fixed is that the web archive, (geode-pulse) has since 1.8
> been uploaded as a jar file to maven central.
> >>>
> >>> I would like to fix this by having the WAR artifact being pushed to
> maven central again.
> >>>
> >>> --Udo
> >>>
> >>
>
>

Re: [DISCUSS] - Upgrading from Spring 4 to Spring 5

[Jens Deppe]

+1

On Wed, Oct 30, 2019 at 1:39 PM Udo Kohlmeyer  wrote:

> Sorry,
>
> To clarify... When we change the Spring version we would be looking at
> looking to use the latest version and it's associated BOM.
>
> That might be inclusive of other Spring project upgrades.
>
> --Udo
>
> On 10/30/19 1:35 PM, Nabarun Nag wrote:
> > Hi Udo,
> > Maven has the latest as 5.2.0.RELEASE as the latest version.  In the
> > Dependency.groovy file, we have been putting the full version number.
> Hence
> > I am guessing you are suggesting we put 5.2.0.RELEASE?
> >
> > What about the status of the following dependencies?
> >
> > 'org.springframework.hateoas', name: 'spring-hateoas', version:
> > '0.25.0.RELEASE'
> > 'org.springframework.ldap', name: 'spring-ldap-core', version:
> > '2.3.2.RELEASE'
> > 'org.springframework.shell', name: 'spring-shell', version:
> '1.2.0.RELEASE'
> >
> > Regards
> > Naba
> >
>

Re: Special certificates for multisite

[Jens Deppe]

Juan,

Let me try and answer just to ensure that *I* fully understand the use case.

>From an 'alias' POV this could be seen as having the ability for a *single*
component (locator, server, etc) to have multiple (dynamic) aliases. So,
depending on where the connection originated *from* a particular
certificate is chosen.

Currently we only have the ability to associate a single certificate with
an individual component.

--Jens

On Fri, Nov 1, 2019 at 10:51 AM Ju@N  wrote:

> Hello Alberto,
>
> I'm not particularly knowledgeable on this subject so I might be missing
> something, but with Geode you can independently configure SSL for specific
> system components, can't you just use multiple alias to achieve your use
> case as described here [1]?.
>
> *>> 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.*
> Here you would use *cluster *as the alias to configure the SSL settings
> used for communications within one geographical site, and *gateway *as the
> alias to configure the particular SSL settings to be used for
> communications across sites. Would that work for you?.
>
> Cheers.
>
> [1]:
>
> https://geode.apache.org/docs/guide/110/managing/security/implementing_ssl.html
>
>
> On Fri, Nov 1, 2019 at 1:37 PM Anthony Baker  wrote:
>
> > Just checking, is anyone familiar enough with SSL to comment on the
> > proposed change?
> >
> > Anthony
> >
> >
> > > On Oct 29, 2019, at 2:44 AM, Mario Ivanac 
> wrote:
> > >
> > > 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<
> > https://tools.ietf.org/html/rfc6066#page-6> 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.
> > >
> > >
> > >
> >
> >
>
> --
> Ju@N
>

Re: Special certificates for multisite

[Jens Deppe]

I think it sounds pretty reasonable. Given that the only change to Geode
would be the suggested update to the ClientHello and we shouldn't need to
make any additional changes in order to leverage the functionality.
Presumably the custom Provider would need to be installed by the user and
configured for use in the JDK's java.security file.

The only downside would be if someone ever came up with a 'legitimate' use
for this extension that required the use of an actual server name.

--Jens

On Fri, Nov 1, 2019 at 6:37 AM Anthony Baker  wrote:

> Just checking, is anyone familiar enough with SSL to comment on the
> proposed change?
>
> Anthony
>
>
> > On Oct 29, 2019, at 2:44 AM, Mario Ivanac  wrote:
> >
> > 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<
> https://tools.ietf.org/html/rfc6066#page-6> 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.
> >
> >
> >
>
>

[ANNOUNCE] Apache Geode 1.9.2

[Jens Deppe]

The Apache Geode community is pleased to announce the availability of
Apache Geode 1.9.2.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode 1.9.2 contains a number of improvements and bug fixes.


   - Added the ability to specify that when an asynchronous event queue
   (AEQ) first starts, event processing should be paused. A `resume` command
   is provided to start event processing at the desired time. Three gfsh
   commands were added or modified to support this capability: "create
   async-event-queue --pause-event-processing", "alter async-event-queue
   --pause-event-processing", and "resume async-event-queue-dispatcher". See
   the gfsh command reference in the Geode User Guide for details.
   - Publish war artifacts for geode-web , geode-web-api and
   geode-web-management to Maven Central.
   - Fix compatibility with launching geode-web (admin REST API) when
   Spring 5.x jars are on the classpath.


For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/19/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Jens Deppe on behalf of the Apache Geode team

Re: [VOTE] Apache Geode 1.9.2.RC1

[Jens Deppe]

It's past the announced deadline and we have enough votes to close the vote.

Voting status
==
+1: 5 binding votes, 3 non-binding votes
* Udo Kohlmeyer (PMC member)
* Juan Ramos (PMC member)
* Dave Barnes (PMC member)
* Jinmei Liao (PMC member)
* John Blum (PMC member)

+0: zero votes

-0: zero votes

-1: 1 non-binding vote

The voting meets the requirements of at least 3 PMC members with +1 votes
and has the required majority of +1 votes.
Apache Geode 1.9.2.RC1 passed the vote and we will finalize the release
shortly.

Thanks everyone for taking the time to look over this release!

--Jens

On Mon, Oct 21, 2019 at 8:20 AM Jens Deppe  wrote:

> Since the deadline has expired without enough votes, I am going to extend
> it for another 48(ish) hours until 8am PST, Wednesday , 23rd October.
>
> Thanks
> --Jens
>
> On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe  wrote:
>
>> Hello Geode Dev Community,
>>
>> This is a release candidate for Apache Geode version 1.9.2.RC1.
>> Thanks to all the community members for their contributions to this
>> release!
>>
>> Please do a review and give your feedback, including the checks you
>> performed.
>>
>> Voting deadline:
>> 3PM PST Sun, October 20 2019.
>>
>> Please note that we are voting upon the source tag:
>> rel/v1.9.2.RC1
>>
>> Release notes:
>>
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
>>
>> Source and binary distributions:
>> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
>>
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeode-1060
>>
>> GitHub:
>> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
>> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
>> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
>>
>> Pipelines:
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
>>
>> Geode's KEYS file containing PGP keys we use to sign the release:
>> https://github.com/apache/geode/blob/develop/KEYS
>>
>> Command to run geode-examples:
>> ./gradlew -PgeodeReleaseUrl=
>> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
>> -PgeodeRepositoryUrl=
>> https://repository.apache.org/content/repositories/orgapachegeode-1060
>> build runAll
>>
>> Regards
>> --Jens
>>
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Jens Deppe]

Hi Owen,

As this vote is now closing I'd like to quickly comment on your
(non-binding) vote.

I understand your concern that these changes are not currently on the 1.10
branch, however I think that concern is somewhat premature as we may never
end up with a 1.10.1 release. If that does happen we will definitely port
these changes over.

Thanks
--Jens

On Tue, Oct 15, 2019 at 3:06 PM Owen Nichols  wrote:

> I am concerned that this 1.9.2 release contains features that are not in
> 1.10:
> GEODE-7241 Publish war artifacts for geode-web , geode-web-api and
> geode-web-management to Maven Central.
> GEODE-7261 Fix compatibility with launching geode-web (admin REST API)
> when Spring 5.x jars are on the classpath.
>
> My concern is that users of these 1.9.2 fixes will be surprised to
> experience a regression when they upgrade to 1.10.0.
>
> This could be addressed by planning a 1.10.1 patch release, or maybe just
> by documenting this caveat as long as the Spring Data project can agree to
> skip over 1.10, but my non-binding vote is -1 until some plan is in place.
>
> -Owen
>
> > On Oct 15, 2019, at 10:47 AM, Jens Deppe  wrote:
> >
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.9.2.RC1.
> > Thanks to all the community members for their contributions to this
> release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 3PM PST Sun, October 20 2019.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.9.2.RC1
> >
> > Release notes:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1060
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> > https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> > https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> >
> > Pipelines:
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1060
> > build runAll
> >
> > Regards
> > --Jens
>
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Jens Deppe]

Since the deadline has expired without enough votes, I am going to extend
it for another 48(ish) hours until 8am PST, Wednesday , 23rd October.

Thanks
--Jens

On Tue, Oct 15, 2019 at 10:47 AM Jens Deppe  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.9.2.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Sun, October 20 2019.
>
> Please note that we are voting upon the source tag:
> rel/v1.9.2.RC1
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1060
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> build runAll
>
> Regards
> --Jens
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Jens Deppe]

No worries and thanks for taking the time to look at the bits!

--Jens

On Wed, Oct 16, 2019 at 2:21 PM Blake Bender  wrote:

> Okay I'm convinced we're okay, so switching to a +1.  Standard PEBKAC error
> here, I managed to produce a native client build which was missing the jar
> file we use for a whole bunch of tests, so all failed.
>
> Thanks,
>
> Blake
>
>
> On Wed, Oct 16, 2019 at 1:03 PM Blake Bender  wrote:
>
> > I'm a -1 on this one, for the time being, sorry.  I ran native client
> > integration tests against it on my dev workstation and am seeing an
> > inordinate number of failures.  It's gonna take me some time to
> understand
> > what's going on, but I'll update everyone shortly as to whether I think
> we
> > have a real issue.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Tue, Oct 15, 2019 at 3:29 PM Udo Kohlmeyer  wrote:
> >
> >> Hi there Owen,
> >>
> >> Whilst I share your concern of consistence, the Geode user community did
> >> not notice that the artifacts changed from war -> jar (GEODE-7241). The
> >> Spring Data Geode project is currently the only downstream project which
> >> discovered this regression.
> >>
> >> As Spring Data Geode 2.2 will not be using any other version than 1.9.x,
> >> there is no dependency on 1.10.
> >>
> >> In addition to this, 1.11 is not that far off, and upon discovery of
> >> this regression from 1.9.2 -> 1.10, we most likely could be pointing
> >> them at 1.11 to upgrade.
> >>
> >> As for Spring 5 (GEODE-7261), I might agree that we might want to be
> >> adding that to 1.10.1 patch, but so far I have not seen/heard of any
> >> users hitting this issue. Maybe it would also fall into the category of
> >> "wait for 1.11".
> >>
> >> --Udo
> >>
> >> On 10/15/19 3:05 PM, Owen Nichols wrote:
> >> > I am concerned that this 1.9.2 release contains features that are not
> >> in 1.10:
> >> > GEODE-7241 Publish war artifacts for geode-web , geode-web-api and
> >> geode-web-management to Maven Central.
> >> > GEODE-7261 Fix compatibility with launching geode-web (admin REST API)
> >> when Spring 5.x jars are on the classpath.
> >> >
> >> > My concern is that users of these 1.9.2 fixes will be surprised to
> >> experience a regression when they upgrade to 1.10.0.
> >> >
> >> > This could be addressed by planning a 1.10.1 patch release, or maybe
> >> just by documenting this caveat as long as the Spring Data project can
> >> agree to skip over 1.10, but my non-binding vote is -1 until some plan
> is
> >> in place.
> >> >
> >> > -Owen
> >> >
> >> >> On Oct 15, 2019, at 10:47 AM, Jens Deppe 
> wrote:
> >> >>
> >> >> Hello Geode Dev Community,
> >> >>
> >> >> This is a release candidate for Apache Geode version 1.9.2.RC1.
> >> >> Thanks to all the community members for their contributions to this
> >> release!
> >> >>
> >> >> Please do a review and give your feedback, including the checks you
> >> >> performed.
> >> >>
> >> >> Voting deadline:
> >> >> 3PM PST Sun, October 20 2019.
> >> >>
> >> >> Please note that we are voting upon the source tag:
> >> >> rel/v1.9.2.RC1
> >> >>
> >> >> Release notes:
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> >> >>
> >> >> Source and binary distributions:
> >> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> >> >>
> >> >> Maven staging repo:
> >> >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >> >>
> >> >> GitHub:
> >> >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> >> >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> >> >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> >> >>
> >> >> Pipelines:
> >> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> >> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> >> >>
> >> >> Geode's KEYS file containing PGP keys we use to sign the release:
> >> >> https://github.com/apache/geode/blob/develop/KEYS
> >> >>
> >> >> Command to run geode-examples:
> >> >> ./gradlew -PgeodeReleaseUrl=
> >> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> >> -PgeodeRepositoryUrl=
> >> >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >> >> build runAll
> >> >>
> >> >> Regards
> >> >> --Jens
> >> >
> >>
> >
>

[VOTE] Apache Geode 1.9.2.RC1

[Jens Deppe]

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.9.2.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you
performed.

Voting deadline:
3PM PST Sun, October 20 2019.

Please note that we are voting upon the source tag:
rel/v1.9.2.RC1

Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1060

GitHub:
https://github.com/apache/geode/tree/rel/v1.9.2.RC1
https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1

Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS

Command to run geode-examples:
./gradlew -PgeodeReleaseUrl=
https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1 -PgeodeRepositoryUrl=
https://repository.apache.org/content/repositories/orgapachegeode-1060
build runAll

Regards
--Jens

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

[Jens Deppe]

Thank you for the approvals. I will include these changes in 1.9.2

--Jens

On Mon, Oct 14, 2019 at 11:21 AM John Blum  wrote:

> +1
>
> On Mon, Oct 14, 2019 at 11:19 AM Udo Kohlmeyer  wrote:
>
> > +1 to including both.
> >
> > On 10/14/19 10:52 AM, Dick Cavender wrote:
> > > +1 for both fixes and the original list
> > >
> > >
> > > On Mon, Oct 7, 2019 at 5:00 PM Owen Nichols 
> wrote:
> > >
> > >> Sounds like a big win for convenience, and clearly a regression
> relative
> > >> to the last release of Geode that SBDG picked up (1.6).  Thanks for
> > >> clarifying what is at stake.
> > >>
> > >> +1 for including both fixes
> > >>
> > >>> On Oct 7, 2019, at 4:50 PM, Udo Kohlmeyer  wrote:
> > >>>
> > >>> Hi there Owen,
> > >>>
> > >>> I apologize if it is not clear.
> > >>>
> > >>> GEODE-7241 is a regression where the published artifact "geode-web"
> and
> > >> "geode-web-api" were published as jars and not wars.
> > >>> NOW, why is it critical for 1.9.x... Well, the answer is fairly
> short.
> > >> In Spring Data Geode, there is an ability to start/bootstrap a server
> > using
> > >> Spring Data Geode(SDG) only. This feature can be used for testing as
> > well
> > >> as starting a Server using SDG. In order to start the server using
> SDG,
> > all
> > >> that is required is to add the geode-web + geode-web-api artifacts
> onto
> > the
> > >> classpath as a maven/gradle dependency. There is no more requirement
> to
> > >> download the project and reference libs or using GFSH to start the
> > server.
> > >>> WHEN the extension went from war -> jar, this functionality was
> broken.
> > >> The latest version of SDG (2.2.x) will be based on Geode 1.9. and not
> > 1.10+
> > >> which means that SDG will not gain that functionality. SDG would have
> to
> > >> wait for its next release 2.3.x, which is still quite some way off.
> > >>> Usually this is not a big thing, but given Spring's prescribed manner
> > of
> > >> handling versions of dependent libraries, the version of Geode cannot
> be
> > >> changed and only patch versions are allowed. So, in order to address
> the
> > >> regression, a patch to 1.9.x is requested.
> > >>> Hope that this explains it a little better.
> > >>>
> > >>> --Udo
> > >>>
> > >>> On 10/7/19 3:50 PM, Owen Nichols wrote:
> > >>>> I don’t yet have a clear understanding of what makes these critical,
> > >>>> especially GEODE-7241. Can you elaborate, including:
> > >>>> * Are these fixes already in 1.10?  If not, would a 1.10.1 patch be
> > >>>> required as well?
> > >>>> * What is the impact of not including each of these fixes?  Is
> there a
> > >>>> workaround?
> > >>>>
> > >>>> On Fri, Oct 4, 2019 at 10:44 AM Jens Deppe 
> wrote:
> > >>>>
> > >>>>> I'd like to propose adding these two fixes to release/1.9.2
> > >>>>>
> > >>>>> GEODE-7261 ensures that the Admin REST service can start when
> Spring
> > >> Boot
> > >>>>> Data Geode is used to launch a server.
> > >>>>>
> > >>>>> GEODE-7241 publishes our various war artifacts to maven. This
> ensures
> > >> that,
> > >>>>> in the context of starting a SBDG server, the necessary REST wars
> can
> > >> be
> > >>>>> made available in order to start the required REST services.
> > >>>>>
> > >>>>> Thanks
> > >>>>>
> > >>>>> --Jens
> > >>>>>
> > >>
> >
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

[Jens Deppe]

Bump - reminder for folks to consider these two changes be included in
Geode 1.9.2

Thanks
--Jens

On Fri, Oct 4, 2019 at 12:57 PM Juan José Ramos  wrote:

> +1
>
> On Fri, Oct 4, 2019 at 6:44 PM Jens Deppe  wrote:
>
> > I'd like to propose adding these two fixes to release/1.9.2
> >
> > GEODE-7261 ensures that the Admin REST service can start when Spring Boot
> > Data Geode is used to launch a server.
> >
> > GEODE-7241 publishes our various war artifacts to maven. This ensures
> that,
> > in the context of starting a SBDG server, the necessary REST wars can be
> > made available in order to start the required REST services.
> >
> > Thanks
> >
> > --Jens
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>

Re: [DISCUSS] add GEODE-7079 to release/1.9.2

[Jens Deppe]

Thank you for your votes. GEODE-7079 will now be added to the 1.9.2 release.

--Jens

On Fri, Oct 4, 2019 at 12:51 PM Eric Shu  wrote:

> +1
>
>
> On Fri, Oct 4, 2019 at 11:38 AM Anilkumar Gingade 
> wrote:
>
> > +1
> >
> > On Fri, Oct 4, 2019 at 11:15 AM Juan José Ramos 
> wrote:
> >
> > > +1
> > >
> > >
> > >
> > >
> > > On Fri, Oct 4, 2019 at 6:39 PM Jens Deppe  wrote:
> > >
> > > > On behalf of Juan I'm requesting approval to add GEODE-7079 to
> > > > release/1.9.2
> > > >
> > > > The original justification is:
> > > >
> > > > Long story short: GEODE-7079 can be hit by *spring-data-geode* users
> > that
> > > > restart a member configured with a persistent asynchronous event
> queue
> > > > (with conflation enabled) without pausing the event processor. The
> > > ability
> > > > to pause the event processor is what we're mainly adding in 1.9.2,
> > that's
> > > > why I believe this fix should also be included.
> > > >
> > > > Thanks
> > > > --Jens
> > > >
> > >
> > >
> > > --
> > > Juan José Ramos Cassella
> > > Senior Software Engineer
> > > Email: jra...@pivotal.io
> > >
> >
>

Re: Token based authentication support added in Geode Develop

[Jens Deppe]

So, to be clear, we're providing the ability to recognize a HTTP
authentication header containing 'Bearer ' and
then handing that to the Security Manager to do with as it pleases?

We're not doing anything with actual token management? (i.e. generating,
revoking, etc.).

--Jens

On Fri, Oct 4, 2019 at 10:59 AM Jinmei Liao  wrote:

> Hi, all
>
> JWT token based authentication support is added to Geode develop branch.
> Currently only management v2 rest api can use this (we can add dev rest
> there too if requested). In order to turn on token based auth for
> management rest api, you will need to do these two things:
> 1. start your locator with this property:
>  *security-auth-token-enabled-components = all (or management)*
> 2. implement your SecurityManager to authenticate the jwt token passed in.
> The jwt token will be available in the properties using the key
> "security-token".
>
> Let me know if you have any questions.
>
> --
> Cheers
>
> Jinmei
>

[DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

[Jens Deppe]

I'd like to propose adding these two fixes to release/1.9.2

GEODE-7261 ensures that the Admin REST service can start when Spring Boot
Data Geode is used to launch a server.

GEODE-7241 publishes our various war artifacts to maven. This ensures that,
in the context of starting a SBDG server, the necessary REST wars can be
made available in order to start the required REST services.

Thanks

--Jens

[DISCUSS] add GEODE-7079 to release/1.9.2

[Jens Deppe]

On behalf of Juan I'm requesting approval to add GEODE-7079 to release/1.9.2

The original justification is:

Long story short: GEODE-7079 can be hit by *spring-data-geode* users that
restart a member configured with a persistent asynchronous event queue
(with conflation enabled) without pausing the event processor. The ability
to pause the event processor is what we're mainly adding in 1.9.2, that's
why I believe this fix should also be included.

Thanks
--Jens

Re: [Announce] Release branch 1.9.2 created

[Jens Deppe]

I have issued a separate email thread for inclusion of GEODE-7241 and
GEODE-7261

On Fri, Oct 4, 2019 at 10:32 AM Udo Kohlmeyer  wrote:

> Hi there Owen,
>
> Thank you for pointing out the missed process.
>
> @Jens, I think the majority of the GEODE tickets listed are related to
> the AEQ pause feature. If so, it might be best to group them, in order
> to best gauge which tickets need to be discussed to be included in the
> release.
>
> --Udo
>
> On 10/4/19 10:13 AM, Owen Nichols wrote:
> > I can see that the AEQ pause feature was previously discussed and
> approved:
> >
> https://lists.apache.org/thread.html/9b5f5c58e1b298d9d0ca870a0deec06f7344a60809790c75a5f68bfa@%3Cdev.geode.apache.org%3E
> <
> https://lists.apache.org/thread.html/9b5f5c58e1b298d9d0ca870a0deec06f7344a60809790c75a5f68bfa@%3Cdev.geode.apache.org%3E
> >
> >
> > However I don’t see any discussion or approval for the proposal to
> include "GEODE-7261: Include spring-core in the geode-web war artifact”:
> >
> https://lists.apache.org/thread.html/5b1a20fc287bf0322257da3b8d22d56b968730419627dd08f93146f0@%3Cdev.geode.apache.org%3E
> <
> https://lists.apache.org/thread.html/5b1a20fc287bf0322257da3b8d22d56b968730419627dd08f93146f0@%3Cdev.geode.apache.org%3E
> >
> >
> > If Spring 5 pairs with SDG 2.2.0, then it should be easy to make a
> proposal for why GEODE-7261 is a critical fix and within the theme of
> 1.9.2.  I’d just like to see a discussion and vote for every fix backported
> into the release branch.
> >
> > -Owen
> >
> >> On Oct 4, 2019, at 6:46 AM, Jens Deppe  wrote:
> >>
> >> Hello Geode Dev Community,
> >>
> >> We have created a new release branch for Apache Geode 1.9.2 -
> "release/1.9.2"
> >>
> >>
> >> This branch currently includes the following commits:
> >>
> >>
> >> GEODE-7124: Fixing tests for older version
> >> GEODE-7204: Add changes to AEQ documentation for
> >> 'pause-event-processing' functionality (#4053)
> >> GEODE-7179: alter async queue command to change state of event
> >> processor during creation (#4057)
> >> GEODE-7128: APIs and GFSH commands to resume AEQ processing. (#4056)
> >> GEODE-7149: Changes to support AsyncEventQueue's dispatcher status
> >> with AsyncEventQueue beans (#4029)
> >> GEODE-7127: Fixing the list AEQ command.
> >> GEODE-7127: Added gfsh arguments for starting AEQ with paused event
> processing.
> >> GEODE-7126: Refactoring API names to be more consistent.
> >> GEODE-7129: Adding XML config for creating AEQ with paused event
> processing.
> >> GEODE-7126: Added new API to resume AEQ event processing
> >> GEODE-7124: Added new API to create AEQ with paused event processing
> >> GEODE-7261: Include spring-core in the geode-web war artifact
> >>
> >> Please do review and raise any concern with the release branch.
> >> If no concerns are raised, we will start with the voting for the
> >> release candidate soon.
> >>
> >> Regards
> >> --Jens
> >
>

Re: [Announce] Release branch 1.9.2 created

[Jens Deppe]

Hi Juan,

The purpose of this release is to provide fixes that are required for the
Spring Data Geode project. Since the current release of SDG (2.2.0.RELEASE)
is based against Geode 1.9.1, it cannot be bumped to any newer (major or
even minor) version that may contain fixes it requires. Thus, for the
current release of SDG, any necessary Geode fixes will need to be made
against 1.9.x.

With that in mind, unless GEODE-7079 is affecting SDG (or SBDG), I do not
wish to add it.

Thanks for your understanding
--Jens

On Fri, Oct 4, 2019 at 7:09 AM Juan José Ramos  wrote:

> Hello Jens,
>
> Can we add *GEODE-7079 [1]* to this release branch as well?.
> The fix basically prevents a NPE during restart of members that have
> configured asynchronous event distribution (either WAN replication of async
> event listener) & conflation.
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7079
>
> On Fri, Oct 4, 2019 at 2:49 PM Robert Houghton 
> wrote:
>
> > I'm about to merge the war pr into develop.
> >
> > On Fri, Oct 4, 2019, 06:47 Jens Deppe  wrote:
> >
> > > Hello Geode Dev Community,
> > >
> > > We have created a new release branch for Apache Geode 1.9.2 -
> > > "release/1.9.2"
> > >
> > >
> > > This branch currently includes the following commits:
> > >
> > >
> > > GEODE-7124: Fixing tests for older version
> > > GEODE-7204: Add changes to AEQ documentation for
> > > 'pause-event-processing' functionality (#4053)
> > > GEODE-7179: alter async queue command to change state of event
> > > processor during creation (#4057)
> > > GEODE-7128: APIs and GFSH commands to resume AEQ processing. (#4056)
> > > GEODE-7149: Changes to support AsyncEventQueue's dispatcher status
> > > with AsyncEventQueue beans (#4029)
> > > GEODE-7127: Fixing the list AEQ command.
> > > GEODE-7127: Added gfsh arguments for starting AEQ with paused event
> > > processing.
> > > GEODE-7126: Refactoring API names to be more consistent.
> > > GEODE-7129: Adding XML config for creating AEQ with paused event
> > > processing.
> > > GEODE-7126: Added new API to resume AEQ event processing
> > > GEODE-7124: Added new API to create AEQ with paused event processing
> > > GEODE-7261: Include spring-core in the geode-web war artifact
> > >
> > > Please do review and raise any concern with the release branch.
> > > If no concerns are raised, we will start with the voting for the
> > > release candidate soon.
> > >
> > > Regards
> > > --Jens
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>

[Announce] Release branch 1.9.2 created

[Jens Deppe]

Hello Geode Dev Community,

We have created a new release branch for Apache Geode 1.9.2 - "release/1.9.2"


This branch currently includes the following commits:


GEODE-7124: Fixing tests for older version
GEODE-7204: Add changes to AEQ documentation for
'pause-event-processing' functionality (#4053)
GEODE-7179: alter async queue command to change state of event
processor during creation (#4057)
GEODE-7128: APIs and GFSH commands to resume AEQ processing. (#4056)
GEODE-7149: Changes to support AsyncEventQueue's dispatcher status
with AsyncEventQueue beans (#4029)
GEODE-7127: Fixing the list AEQ command.
GEODE-7127: Added gfsh arguments for starting AEQ with paused event processing.
GEODE-7126: Refactoring API names to be more consistent.
GEODE-7129: Adding XML config for creating AEQ with paused event processing.
GEODE-7126: Added new API to resume AEQ event processing
GEODE-7124: Added new API to create AEQ with paused event processing
GEODE-7261: Include spring-core in the geode-web war artifact

Please do review and raise any concern with the release branch.
If no concerns are raised, we will start with the voting for the
release candidate soon.

Regards
--Jens

Re: Request for bulk change permission

[Jens Deppe]

Looks good. Thanks Dan!

On Tue, Oct 1, 2019 at 11:32 AM Dan Smith  wrote:

> I think you should have permissions now.
>
> -Dan
>
>
>
> On Tue, Oct 1, 2019 at 10:00 AM Jens Deppe  wrote:
>
> > I don't seem to have this - please could someone grant it.
> >
> > Thanks
> > --Jens
> >
>

Request for bulk change permission

[Jens Deppe]

I don't seem to have this - please could someone grant it.

Thanks
--Jens

Re: Cutting Geode 1.9.2

[Jens Deppe]

I'll give it a shot - actually Patrick and I will pair on it.

--Jens

On Fri, Sep 27, 2019 at 11:08 AM Udo Kohlmeyer 
wrote:

> Hi there Geode Dev's,
>
> There seems to be consensus on cutting Geode 1.9.2.
>
> https://lists.apache.org/thread.html/9b5f5c58e1b298d9d0ca870a0deec06f7344a60809790c75a5f68bfa@%3Cdev.geode.apache.org%3E
>
> Would there be any willing candidates who would raise their hand to
> shepherd this release? Maybe some one from our newer/younger committers?
>
> --Udo
>
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jens Deppe]

Somewhat related to this - I've found that the V1 Admin Rest API
(geode-web) will not start when Spring 5 libs are on the classpath. I've
raised https://issues.apache.org/jira/browse/GEODE-7261. I'd like to see
this included too.

--Jens

On Mon, Sep 30, 2019 at 12:35 PM Udo Kohlmeyer  wrote:

> @Robert, I think the consensus is that WAR is the correct option.
>
> So unless someone objects, GEODE-7241 is a GO!
>
> --Udo
>
> On 9/30/19 10:58 AM, Robert Houghton wrote:
> > I am unclear on the consensus of this thread.
> >
> > On Wed, Sep 25, 2019 at 12:55 PM John Blum  wrote:
> >
> >> @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
> >> heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
> >>
> >> On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett 
> >> wrote:
> >>
> >>> Udo,
> >>>
> >>> I didn’t say we shouldn’t fix it for the future. I said I don’t believe
> >> it
> >>> warrants a backport and a patch release.
> >>>
> >>> -Jake
> >>>
> >>>
> >> --
> >> -John
> >> john.blum10101 (skype)
> >>
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jens Deppe]

I also cannot recall any reason as to the need to *publish* wars.

However, please do not change the files to .jar. To John's point, despite
the lack of some dependent jars, the structure still conforms to a .war
format.

--Jens

On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:

> Actually, to clarify 2 points.
>
> 1. Technically, it is a bit more involved than simply just validating the
> "format".  For instance, the web.xml file must be valid and well-formed.
> 2. There was a reason why the geode-core and other Apache Geode libs were
> not bundled in WEB-INF/lib of the WAR files, since then it would create
> duplication on the global as well as the WAR file's (isolated) ClassLoader
> classpath, particularly for the "embedded" Geode Servlet Container case,
> and as such, ClassLoader problems would occur.
>
>
>
> On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
>
> > Udo,
> >
> > Can you update GEODE-7241 to help us understand the reason why we need to
> > publish geode-web* WARs to maven?  I get that we used to do this but I
> > can’t recall why we choose that approach.
> >
> > There is one request for Pulse on maven (GEODE-6208).
> >
> > Anthony
> >
> >
> > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > >
> > > Maybe the better question is, WHY are we publishing geode-web and
> > geode-web-api.
> > >
> > > Pulse, from what I remember, could be a standalone deployment. At least
> > that is what I remember.
> > >
> > > Most likely an oversight...
> > >
> > > --Udo
> > >
> > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > >> The geode-pulse module also builds a war, but does not publish it. Is
> > this
> > >> an oversight, or by design?
> > >>
> > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton  >
> > >> wrote:
> > >>
> > >>> I am working on the change to get the geode-web and geode-web-api war
> > >>> artifacts published instead of the jars. I have found the
> > >>> geode-web-management project is also producing a war artifact, in
> > addition
> > >>> to a jar. Do we want it to be published as well? What is the
> criterion
> > we
> > >>> use to decide?
> > >>>
> > >>> I think this problem was an oversight from the changes PurelyApplied
> > and I
> > >>> made to the build when we made the publish plugin 'opt-in' instead of
> > >>> forced by the root project. Easy to publish one or the other, but I
> am
> > not
> > >>> qualified to decide whether a war or jar is more appropriate for
> these
> > >>> modules.
> > >>>
> > >>> Thank you,
> > >>> -Robert
> > >>>
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>

Re: [DISCUSS] - Cutting of release 1.9.2

[Jens Deppe]

+1 for creating a 1.9.2 release with this fix.

On Fri, Sep 20, 2019 at 2:00 PM Udo Kohlmeyer  wrote:

> John, thank you!
>
> You are correct, not sure what I was thinking.. Geode 1.9.x IS used by
> SDG 2.2
>
> On 9/20/19 1:11 PM, John Blum wrote:
> > Correction to *Udo's* comments!
> >
> > SDG Moore/2.2 is based on Apache Geode 1.9, NOT SDG Lovelace/2.1 (which
> is
> > based on Apache Geode 1.6).
> >
> > You can review the version compatibility matrix beginning with SBDG,
> here (
> >
> https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix
> > ).
> >
> > On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:
> >
> >> Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which
> is
> >> tentatively scheduled for Monday, Sept. 30th.
> >>
> >> On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:
> >>
> >>> Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG
> 2.2.0?
> >>>
> >>> On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:
> >>>
>  Hi there Geode Dev's,
> 
>  I would like to propose a release for Geode 1.9.x that includes
>  https://issues.apache.org/jira/browse/GEODE-7121.
> 
>  This is an issue that is current in the 1.9.x branch, which is used by
>  Spring Data Geode 2.1.10 <
> https://spring.io/projects/spring-data-geode
>  .
> 
>  This issue can cause an application using Spring Data Geode to
> bootstrap
>  GEODE to deadlock upon start up.
> 
>  This is critical system's issue and given that Spring Data Geode
> cannot
>  change its underlying dependency to 1.10+, would require this fix to
> be
>  back-ported to the 1.9 branch.
> 
>  --Udo
> 
> 
> >>
> >> --
> >> -John
> >> john.blum10101 (skype)
> >>
> >
>

Re: [VOTE] Adding new AEQ feature to release/1.10.0

[Jens Deppe]

+1

On Mon, Sep 16, 2019 at 3:08 AM Juan José Ramos  wrote:

> +1
>
> On Fri, Sep 13, 2019 at 11:59 PM Ryan McMahon 
> wrote:
>
> > +1
> >
> > On Fri, Sep 13, 2019 at 3:58 PM Donal Evans  wrote:
> >
> > > +1
> > >
> > > On Fri, Sep 13, 2019 at 3:37 PM Benjamin Ross 
> wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Sep 13, 2019 at 3:25 PM Anilkumar Gingade <
> aging...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > +1. This is needed for spring data-geode; whose upcoming release is
> > > based
> > > > > on older geode version.
> > > > >
> > > > > -Anil.
> > > > >
> > > > >
> > > > > On Fri, Sep 13, 2019 at 3:23 PM Nabarun Nag 
> wrote:
> > > > >
> > > > > > Hi Geode Community ,
> > > > > >
> > > > > > [GEODE-7121]
> > > > > >
> > > > > > I would like to include the new feature of creating AEQs with a
> > > paused
> > > > > > event processor to the release 1.10 branch. This also includes
> the
> > > > > feature
> > > > > > to resume the AEQ at a later point in time.
> > > > > > This feature includes addition of new/modified APIs and gfsh
> > > commands.
> > > > > >
> > > > > > [All details about this feature has been discussed in a previous
> > > > discuss
> > > > > > thread]
> > > > > >
> > > > > > These are the commits that needs to be in release 1.10.0 branch.
> > > > > > f6e11084daa30791f7bbf9a8187f6d1bc9c4b91a
> > > > > > 615d3399d24810126a6d57b5163f7afcd06366f7
> > > > > > 1440a95e266e671679a623f93865c5e7e683244f
> > > > > > 42e07dc9054794657acb40c292f3af74b79a1ea6
> > > > > > e1f200e2f9e77e986d250fde3848dc004b26a7c2
> > > > > > 5f70160fba08a06c7e1fc48c7099e63dd1a0502b
> > > > > > 0645446ec626bc351a2c881e4df6a4ae2e75fbfc
> > > > > > 575c6bac115112df1e84455b052566c75764b0be
> > > > > > 3d9627ff16443f4aa513a67bcc284e68953aff8a
> > > > > > ea22e72916f8e34455800d347690e483727f9bf5
> > > > > > 8d26d595f5fb94ff703116eb91bb747e9ba7f536
> > > > > >
> > > > > > Will create a PR ASAP.
> > > > > >
> > > > > > Regards
> > > > > > Nabarun Nag
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>

Re: [Proposal] Make gfsh "stop server" command synchronous

[Jens Deppe]

To circle back to the original test failure that prompted this discussion -
the failing test was getting intermittent bind exceptions on subsequent
server restarts.

I believe it's quite likely that a process' ports will remain unavailable
even after it is gone (I'm not sure if we create listening sockets with
SO_REUSEADDR). So, as to John's comment that gfsh is already synchronous, I
don't think that adding extra functionality to gfsh, to ultimately just
wait longer before exiting, is really solving the problem. I'd suggest you
adjust the tests to always start servers with `--server-port=0` so that
there are no port conflicts and let the OS handle it.

--Jens

On Wed, Sep 11, 2019 at 8:17 AM Bruce Schuchardt 
wrote:

> Blocking or non-blocking, I don't have a strong opinion.  What I'd
> really like to have gfsh ensure, though, is that no-one is able to start
> a new instance of a server while the old process is still around.  Maybe
> the PID file is the way to do that.
>
> On 9/10/19 3:08 PM, Mark Hanson wrote:
> > Hello All,
> >
> > I would like to propose that we make the gfsh “stop server” command
> synchronous. It is causing some issues with some tests as the rest of the
> calls are blocking. Stop on the other hand immediately returns by
> comparison.
> > This causes issues as shown in GEODE-7017 specifically.
> >
> > GEODE:7017 CI failure:
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored
> > https://issues.apache.org/jira/browse/GEODE-7017 <
> https://issues.apache.org/jira/browse/GEODE-7017>
> >
> >
> > What do people think?
> >
> > Thanks,
> > Mark
>

Re: [VOTE] Apache Geode 1.9.1.RC3

[Jens Deppe]

No, It's fixed in 1.10.x.

On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
wrote:

> Hi Jens,
>
> Does this issue appear in 1.10.0.RC1?
>
> On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
>
> > TL;DR: +0
> >
> > When using gfsh over http, the following exception occurs:
> >
> > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > <
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> >
> >
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > at
> >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > at
> >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > at
> >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > at
> >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > at
> >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > at
> >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > at
> >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > at
> >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > at
> >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > at
> >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > at
> >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > at
> >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > at
> >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > at
> > org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > Caused by: java.lang.ClassNotFoundException:
> > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > ... 19 more
> >
> > The problem is that the geode-web.jar is not included in
> > gfsh-dependencies.jar as part of the build.
> >
> > Since this issue appears to also exist on 1.9.0 I'm going to +0 (instead
> of
> > -1). Others may feel differently. A workaround exists simply by adding
> the
> > missing jar when running gfsh.
> >
> > --Jens
> >
> > On Tue, Sep 3, 2019 at 10:45 AM John Blum  wrote:
> >
> > > 1 more thing...
> > >
> > > I would additionally advise rewording the sentence...
> > >
> > > *> Please add log4j-core to the classpath.*
> > >
> > > To read...
> > >
> > > "*Please consider adding log4j-core, or another Logging provider (e.g.
> > > Logback), to your classpath.  Apache Geode works best with Log4j.*"
> > >
> > > Food for thought.
> > >
> > > -John
> > >
> > >
> > > On Tue, Sep 3, 2019 at 10:40 AM John Blum  wrote:
> > >
> > > > +1
> > > >
> > > > Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).
> > > >
> > > > However, can we seriously reconsider logging the follow message at
> > ERROR?
> > > > Ugh!
> > > >
> > > > ERROR Stat

Re: [VOTE] Apache Geode 1.9.1.RC3

[Jens Deppe]

TL;DR: +0

When using gfsh over http, the following exception occurs:

(1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties

Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/geode/management/internal/web/shell/HttpOperationInvoker
at
org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
at
org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
at
org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
at
org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
at
org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
at
org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
at
org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
at
org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
at
org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
at org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
Caused by: java.lang.ClassNotFoundException:
org.apache.geode.management.internal.web.shell.HttpOperationInvoker
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 19 more

The problem is that the geode-web.jar is not included in
gfsh-dependencies.jar as part of the build.

Since this issue appears to also exist on 1.9.0 I'm going to +0 (instead of
-1). Others may feel differently. A workaround exists simply by adding the
missing jar when running gfsh.

--Jens

On Tue, Sep 3, 2019 at 10:45 AM John Blum  wrote:

> 1 more thing...
>
> I would additionally advise rewording the sentence...
>
> *> Please add log4j-core to the classpath.*
>
> To read...
>
> "*Please consider adding log4j-core, or another Logging provider (e.g.
> Logback), to your classpath.  Apache Geode works best with Log4j.*"
>
> Food for thought.
>
> -John
>
>
> On Tue, Sep 3, 2019 at 10:40 AM John Blum  wrote:
>
> > +1
> >
> > Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3).
> >
> > However, can we seriously reconsider logging the follow message at ERROR?
> > Ugh!
> >
> > ERROR StatusLogger Log4j2 could not find a logging implementation. Please
> > add log4j-core to the classpath. Using SimpleLogger to log to the
> console...
> >
> > WARN is more than sufficient.  If no logging provider is on the
> CLASSPATH,
> > it creates a lot of noise!
> >
> > -John
> >
> >
> > On Fri, Aug 30, 2019 at 12:27 PM Dave Barnes  wrote:
> >
> >> +1
> >> Checked the docs: Successfully built viewed the Geode User Guide and the
> >> Javadocs.
> >>
> >> On Fri, Aug 30, 2019 at 11:11 AM Owen Nichols 
> >> wrote:
> >>
> >> > Hello Geode dev community,
> >> >
> >> > This is a release candidate for Apache Geode, version 1.9.1.RC3.
> >> > Thanks to all the community members for their contributions to this
> >> > release!
> >> >
> >> > Please do a review and give your feedback. The deadline is 3PM PST
> Thu,
> >> > September 05 2019.
> >> > Release notes can be found at:
> >> >
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> >> >
> >> > Please note that we are voting upon the source tags: rel/v1.9.1.RC3
> >> >
> >> > Apache Geode:
> >> > https://github.com/apache/geode/tree/rel/v1.9.1.RC3
> >> > Apache Geode examples:
> >> > https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC3
> >> > Apache Geode native:
> >> > https://github.com/apache/geode-native/tree/rel/v1.9.1.RC3
> >> >
> >> > Source and binary files:
> >> > https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC3/
> >> >
> >> > Maven staging repo:
> >> >
> https://repository.apache.org/content/repositories/orgapachegeode-1057
> >> >
> >> > Geode's KEYS file containing PGP keys we use to sign the release:
> >> > 

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

[Jens Deppe]

+1

On Thu, Aug 29, 2019 at 10:39 AM Dave Barnes  wrote:

> What's the deadline this time? Can't be Aug 27...
>
> On Thu, Aug 29, 2019 at 10:04 AM Udo Kohlmeyer  wrote:
>
> > +1
> >
> > On 8/29/19 9:51 AM, John Blum wrote:
> > > +1
> > >
> > > On Thu, Aug 29, 2019 at 9:41 AM Kirk Lund  wrote:
> > >
> > >> +1 (just in case my vote counts)
> > >>
> > >> On Thu, Aug 29, 2019 at 9:02 AM Kirk Lund  wrote:
> > >>
> > >>> Hello Geode dev community,
> > >>>
> > >>> This is a release candidate for Apache Geode, version 1.9.1.RC1.
> > >>> Thanks to all the community members for their contributions to this
> > >>> release!
> > >>>
> > >>> Please do a review and give your feedback. The deadline is 3PM PST
> Tue,
> > >>> August 27 2019.
> > >>> Release notes can be found at:
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > >>>   <
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.1
> > >>> Please note that we are voting on the source tag: rel/v1.9.1.RC1
> > >>>
> > >>> Apache Geode:
> > >>> https://github.com/apache/geode/tree/rel/v1.9.1.RC1 <
> > >>> https://github.com/apache/geode/tree/rel/v1.9.1.RC1>
> > >>> Apache Geode examples:
> > >>> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1 <
> > >>> https://github.com/apache/geode-examples/tree/rel/v1.9.1.RC1>
> > >>> Apache Geode native:
> > >>> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1 <
> > >>> https://github.com/apache/geode-native/tree/rel/v1.9.1.RC1>
> > >>>
> > >>> Source and binary files:
> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/ <
> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1/>
> > >>>
> > >>> Maven staging repo:
> > >>>
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> > <
> > >>>
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> > >
> > >>>
> > >>> Geode's KEYS file containing PGP keys we use to sign the release:
> > >>> https://github.com/apache/geode/blob/develop/KEYS <
> > >>> https://github.com/apache/geode/blob/develop/KEYS>
> > >>>
> > >>> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
> > >>> https://dist.apache.org/repos/dist/dev/geode/1.9.1.RC1
> > >>>   -PgeodeRepositoryUrl=
> > >>>
> https://repository.apache.org/content/repositories/orgapachegeode-1055
> > >> build
> > >>> runAll
> > >>>
> > >>> Regards
> > >>> Owen Nichols & Kirk Lund
> > >>>
> > >
> >
>

Re: Need help: Jetty dunit tests blocking creation of geode-log4j

[Jens Deppe]

I can work with you on this if you're still blocked.

--Jens

On Tue, Aug 20, 2019 at 4:12 PM Kirk Lund  wrote:

> Does anyone know how to debug geode-assembly Jetty dunit tests that fail to
> launch modify_war?
>
> It passes 100% locally in intellij and with gradle cli. It only fails in
> concourse PR precheckin.
>
> Right now, this is the last thing blocking me from submitting a non-draft
> PR to move all log4j-core code from geode-core to geode-log4j. This is
> blocking the creation of geode-log4j.
>
> The only changes in my branch are moving all log4j-core code from
> geode-core to geode-log4j.
>
> If anyone else wants to see this change make it to develop, then I need
> help!
>
> When the test tries to execute modify_war, it fails with the following
> output and stack trace. No other info is available for debugging as
> apparently this kills the gradle daemon.
>
> Failed PR precheckin dunit job:
> https://concourse.apachegeode-ci.info/builds/88240
> PR: https://github.com/apache/geode/pull/3914
>
> > Task :geode-assembly:distributedTest
>
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldHavePersistentSessionData FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
>
> JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05_
>
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
>
> Caused by:
> java.io.IOException: Unable to run modify_war script, command:
>
> [/tmp/geode_container_install17845041006471328987/cargo_modules/Apache_Geode_Modules-1.11.0-SNAPSHOT-AppServer/bin/modify_war,
> -J, -Xmx2096m, -w,
>
> /home/geode/geode/geode-assembly/build/distributedTest254/../../../extensions/session-testing-war/build/libs/session-testing-war.war,
> -t, client-server, -o,
>
> /tmp/geode_container_install17845041006471328987/cargo_wars/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f053692095078744488223.war,
> -p, gemfire.cache.enable_local_cache=true, -p,
>
> gemfire.property.log-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/gemfire.log,
> -p,
>
> gemfire.property.cache-xml-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/cache-client.xml]
> log file:
> ERROR: Error updating web.xml
> ng: INFO: os::commit_memory(0x00077d00, 2147483648, 0)
> failed; error='Not enough space' (errno=12)
>

Re: [DISCUSS] what region types to support in the new management rest api

[Jens Deppe]

Currently, when deployed to the cloud (aka PCC) there is no ability for a
user to group members thus it is also not possible to create regions (via
gfsh at least) that are separated by groups. Typically one would create a
PROXY region against one group and the PARTITION region against another
group. However, without the ability to assign groups, that is not possible.

--Jens

On Tue, Aug 20, 2019 at 7:46 AM Michael Stolz  wrote:

> I know that lots of folks use PROXY regions on the server side to host
> logic associated with the region, but I think they always do that in
> conjunction with server groups so that the proxy is on some of the server
> and the same region containing data is on others. Given the way cache.xml
> works they might not even bother with the server groups, but I'm not sure.
>
> I think we should carry forward the existing shortcuts and not go backward
> to the separate attributes.
>
> --
> Mike Stolz
> Principal Engineer, Pivotal Cloud Cache
> Mobile: +1-631-835-4771
>
>
>
> On Mon, Aug 19, 2019 at 7:59 PM Darrel Schneider 
> wrote:
>
> > Keep in mind that the context of the regions in question is the cluster.
> So
> > these regions would be created on servers.
> > So, for example, does anyone see a need to create PROXY regions on the
> > server? Even if we did not support them on the server, they would still
> be
> > supported on clients.
> >
> >
> > On Mon, Aug 19, 2019 at 4:26 PM Jinmei Liao  wrote:
> >
> > > Region type (in another word Region shortcut) defines a set of
> attributes
> > > for a region. These are the list of region types we have:
> > >
> > > LOCAL,
> > > LOCAL_PERSISTENT,
> > > LOCAL_HEAP_LRU,
> > > LOCAL_OVERFLOW,
> > > LOCAL_PERSISTENT_OVERFLOW,
> > >
> > > PARTITION,
> > > PARTITION_REDUNDANT,
> > > PARTITION_PERSISTENT,
> > > PARTITION_REDUNDANT_PERSISTENT,
> > > PARTITION_OVERFLOW,
> > > PARTITION_REDUNDANT_OVERFLOW,
> > > PARTITION_PERSISTENT_OVERFLOW,
> > > PARTITION_REDUNDANT_PERSISTENT_OVERFLOW,
> > > PARTITION_HEAP_LRU,
> > > PARTITION_REDUNDANT_HEAP_LRU,
> > >
> > > REPLICATE,
> > > REPLICATE_PERSISTENT,
> > > REPLICATE_OVERFLOW,
> > > REPLICATE_PERSISTENT_OVERFLOW,
> > > REPLICATE_HEAP_LRU,
> > >
> > > REPLICATE_PROXY,
> > > PARTITION_PROXY,
> > > PARTITION_PROXY_REDUNDANT,
> > >
> > > In region management rest api, especially in PCC world, we are
> wondering
> > > 1) should we allow users to create LOCAL* regions through management
> rest
> > > api?
> > > 2) should we allow users to create *PROXY regions through management
> rest
> > > api?
> > > 3) for the rest of the PARTITION* and REPLICATE* types, should we
> strive
> > to
> > > keep the region type list the same as before, or only keep the type as
> > > REPLICATE/PARTITION, but use other properties like "redundantCopy" and
> > > "evictionAction" to allow different permutations of region attributes?
> > >
> > > comments appreciated!
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

[Jens Deppe]

This would then imply a SBDG 1.2.1 to include Geode 1.9.1.

On Tue, Aug 13, 2019 at 11:55 AM Anthony Baker  wrote:

> I think there’s value is doing a 1.9.1 patch release to support Spring
> users.
>
> Anthony
>
>
> > On Aug 13, 2019, at 11:26 AM, Kirk Lund  wrote:
> >
> > Udo, Thanks for the info! Sounds like we shouldn't bother with Geode
> 1.9.1
> > then. If I'm misinterpreting what you wrote, let me know.
> >
> > On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer  wrote:
> >
> >> The latest version of SBDG 1.2 is already in RC stage. Which means the
> >> dependent Geode version cannot be changed any more. Currently SBDG 1.2
> >> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
> >> supported, but not changes to 1.10 or later.
> >>
> >> THUS,
> >>
> >> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
> >> Geode, which at this point would be 1.10 or possibly 1.11 depending on
> >> release cycles.
> >>
> >> In addition...
> >>
> >> @Aaron, Whilst it would also be possible to override the underlying
> >> Geode version that SBDG uses, to a later version, I would just like to
> >> point out that all testing of SBDG will be against a named supported
> >> version of Geode / GemFire. Which means, if failures arise using SBDG /
> >> SDG with a non-supported version of Geode / GemFire would effectively be
> >> unsupported. (due diligence to confirm origin of failure will of course
> >> be applied)
> >>
> >> Hope this helps...
> >>
> >> --Udo
> >>
> >> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
> >>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
> >> message, can the next GA release of Spring Boot Data Geode consume 1.10
> >> instead of 1.9? Also, when would SBDG need this patch release by
> (whether
> >> we do a 1.9.1 release or 1.10 release)?
> >>>
> >>> - Aaron
> >>>
>  On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt  >
> >> wrote:
> 
>  If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
> >> communications with conserve-sockets=false is currently broken in 1.9.
> 
>  On 8/13/19 9:25 AM, Kirk Lund wrote:
> > I'd like to discuss if and how we can release Geode 1.9.1 with
> logging
> > improvements. This is primarily to provide a patch release for Spring
> >> Data
> > Geode and Spring Boot to ensure a smoother User experience out-of-the
> >> box.
> > They have very near-future releases that need this as soon as
> possible.
> >
> > The specific tickets and commits that would be back-ported are:
> >
> > *1. GEODE-7058 Log4j-core dependency should be optional in
> geode-core*
> >
> > commit 413800bc16d05df689a2af5c30797f180aad6088
> > Author: Kirk Lund 
> > Date:   Wed Aug 7 14:33:21 2019 -0700
> >
> > GEODE-7058: Mark log4j-core optional in geode-core
> >
> > Note: this change requires all commits from GEODE-2644 and
> >> GEODE-6122.
> >
> > *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
> >
> > commit e5c9c420f462149fd062847904e3435fbe99afb4
> > Author: Kirk Lund 
> > Date:   Thu Aug 8 18:17:32 2019 -0700
> >
> > GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> >> (#3892)
> >
> > This change prevents Geode from using Log4jAgent if Log4j Core is
> > present but not using Log4jProvider.
> >
> > For example, Log4j uses SLF4JProvider when log4j-to-slf4j is in
> >> the
> >classpath.
> >
> > By disabling Log4jAgent when other Log4j Providers are in use,
> >> this
> > prevents problems such as ClassCastExceptions when attemping to
> >> cast
> > loggers from org.apache.logging.slf4j.SLF4JLogger to
> > org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> > LoggerContext.
> >
> > Co-Authored-By: Aaron Lindsey 
> >
> > *3. GEODE-6959 NPE if AlertAppender is not defined*
> >
> > commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
> > Author: Kirk Lund 
> > Date:   Thu Aug 8 14:59:44 2019 -0700
> >
> > GEODE-6959: Prevent NPE in GMSMembershipManager for null
> >> AlertAppender
> > (#3899)
> >
> > If a custom log4j2.xml is used without specifying the Geode
> > AlertAppender,
> > GMSMembershipManager may throw a NullPointerException when
> >> invoking
> > AlertAppender.getInstance().stopSession() during a
> >> forceDisconnect. This
> > change prevents the NullPointerException allowing forceDisconnect
> >> to
> > finish.
> >
> > Users using Spring Boot with Logback are more likely to hit this
> >> bug.
> >
> > Co-authored-by: Mark Hanson mhan...@pivotal.io
> >
> >>
>
>

Re: [DISCUSS] feedback on new experimental Cluster Management Service

[Jens Deppe]

Thanks for starting this thread Owen! I would, however, request that we
keep the thread to one topic, namely feedback about the Cluster Management
Service.

Some background and motivation for this work:

- The intention of this work came about as a need to provide a 'proper' API
with functionality similar to what *gfsh* provides today - i.e. a way to
create Geode components and to persist the configuration. Currently the
former is possible through the Java API (executed on servers) and gfsh, but
the latter is only possible through gfsh.
- The Java API should be available in whatever context the user was
developing (Geode server, Geode client or plain Java app)

--Jens

On Fri, Jul 26, 2019 at 6:54 PM Owen Nichols  wrote:

> Starting with discussions over a year ago, the Geode community recognized
> the need for a new API for cluster management and cluster configuration
> management.  Currently this requires a mix of properties, xml files, and
> gfsh commands.  The envisioned “v2” API would expose identical REST and
> Java APIs and unify the configuration and management experience.
>
> A vast amount of work remains to implement 100% of that vision, but the
> effort reached an important milestone this week.  As of PR 3827 <
> https://github.com/apache/geode/pull/3827>, the REST controllers for the
> handful of commands implemented so far <
> https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API>
> are now enabled by default.  The hope is to start gathering feedback on the
> v2 API vision by making it easier for all users to try it.
>
> Steps have been taken to make it clear that this API could change or be
> removed in a future release:
> - all public classes are annotated @Experimental <
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/annotations/Experimental.html
> >
> - all REST endpoints <
> https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API>
> contain the word “experimental”
> - all REST controllers can be disabled if needed by start locator
> --J=-Dgemfire.enable-management-rest-service=false
>
> Recent discussion about the upcoming 1.10 release have some people
> wondering “Is there a better way to get feedback on something new in Geode?”
>
> Here are a few opinions I’ve heard:
> - it’s fine the way it is (clearly labeled and has a kill switch just in
> case)
> - this kind of work should be happening on a long-lived feature branch,
> not on develop.
> - Geode could have a separate “Technology Preview” release track (somehow
> merging all feature branches).
> - it’s open source; let's encourage all contributions and release often.
> - the community could vote that experimental features in Geode releases
> are ok if and only if they are behind a feature flag which is off by default
> - the community could encourage more frequent discussion of new and
> experimental features so that concerns are raised and mitigated well in
> advance of the next planned release
>
> This thread is open to discussion both on the new Cluster Management
> Service itself, as well as the general process by which feedback on new
> features should be gathered.

Re: IntelliJ setup for develop

[Jens Deppe]

I'd suggest not trying to build with IntelliJ, but delegate to Gradle.
(Search for 'gradle' in Settings and then set 'Build and run using *Gradle*').
You can still run tests with IntelliJ (this is my preference as I feel it's
faster).

On Wed, Jul 24, 2019 at 2:03 PM Sai Boorlagadda 
wrote:

> Building/Rebuilding in IntelliJ fails with error "Cannot start compilation:
> the output path is not specified for modules". Any help would be
> appreciated. I have been following BUILDING.md[1] to setup intellij.
>
> [1] https://github.com/apache/geode/blob/develop/BUILDING.md
>

Re: Requirements for running distributed tests

[Jens Deppe]

Hi Alberto,

Yes, in order to limit the number of concurrent docker test containers you
would use the -PdunitParallelForks variable. As an aside, running without
docker containers would result in the tests running in parallel which is
what you're probably experiencing. To avoid that you should use the gradle
--no-parallel option. Of course, the tests are going to take a lnnnggg
time to run.

I'll see about getting access to the apache-develop-test-container, but in
the meantime I'd suggest just using the Dockerfile to create your own
image. and reference that on the gradle command line with the
-PdunitDockerImage option.

--Jens

On Thu, Jul 18, 2019 at 9:32 AM Alberto Bustamante Reyes
 wrote:

> thanks for the info Jens, we have a better picture now 
>
> Then, gradle is in charge of spin up the containers, isnt it? We see that
> the command used to execute the distributed tests is the following:
>
> gradlew gradlewStrict &&   sed -e 's/JAVA_HOME/GRADLE_JVM/g' -i.bak
> gradlewStrict &&   GRADLE_JVM=/usr/lib/jvm/java-8-openjdk-amd64
> ./gradlewStrict  -PcompileJVM=/usr/lib/jvm/java-8-openjdk-amd64
>  -PcompileJVMVer=8 -PtestJVM=/usr/lib/jvm/java-11-openjdk-amd64
>  -PtestJVMVer=11 -PparallelDunit -PdunitDockerUser=geode
> -PdunitDockerImage=$(docker images --format '{{.Repository}}:{{.Tag}}')
>  -PdunitParallelForks=4 --parallel --console=plain --no-daemon -x
> javadoc -x spotlessCheck -x rat distributedTest
>
> As we were no using any docker image, our tests were running locally, and
> this is why we were getting errors about "ports in use". Is that right?
> Because we did not get any error, so I suppose for gradle its ok not
> getting any docker image for running the tests.
> Where is this container management in the code?
>
> How could we limit the number of containers? With "-PdunitParallelForks"
> parameter? We dont have as much resources as the community to run our CI,
> so we have to adapt the execution.
>
> Regarding the docker image,is it possible to have permissions to download
> the docker image from
> http://gcr.io/apachegeode-ci/apache-develop-test-container ?  I suppose
> the dockerhub image is not being used, as it was updated two years ago and
> the dockerfile was modified three months ago.
>
> thanks again!
> 
> De: Jens Deppe 
> Enviado: miércoles, 17 de julio de 2019 17:41
> Para: dev@geode.apache.org
> Asunto: Re: Requirements for running distributed tests
>
> Hi Alberto,
>
> The images used to run tests on in CI are built here:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-images
> (you
> may see these referred to as 'heavy lifters'). The packer scripts for these
> can be found under here:
> https://github.com/apache/geode/tree/develop/ci/images
>
> The build model is not pure Concourse as, for every test category (ex.
> distributedTest) we programmatically launch one of these 'heavy-lifters',
> copy the code over, and then run the tests.
>
> As you've noted, distributed tests are run inside docker containers. This
> gives isolation so that there are no port/filesystem/network conflicts when
> running tests in parallel. The container used for distributed tests is
> built from this Dockerfile:
> https://github.com/apache/geode/tree/develop/ci/images/test-container.
>
> Windows tests are not run in parallel as we didn't have success in getting
> the parallel dockerization to work consistently; so we only have a subset
> of tests which run in 'normal', serial mode.
>
> Hope this helps.
> --Jens
>
> On Wed, Jul 17, 2019 at 3:47 AM Alberto Bustamante Reyes
>  wrote:
>
> > Hi Geode community,
> >
> > We are trying to set up a CI loop in our Geode fork. We have started with
> > the tests that are run for every pull requests, but we are having
> problems
> > to replicate what is done in the Apache Geode repository, so any help
> will
> > be appreciated.
> > We are not using concour, but we are trying to run the same commands that
> > are run at the end.
> >
> > In the case of distributedTests, if we run them we have problems saying
> > that there are ports in use, which are not present if we run the tests
> > independently ( I mean running for example "geode-core:distributedTest",
> > "geode-cq:distributedTest" instead of just "distributedTest"). So we
> think
> > we are missing something regarding the configuration of the VM where the
> > tests are executed. We have seen there is a custom image used in google
> > cloud (
> > --image-family="${IMAGE_FAMILY_PREFIX}${WINDOWS_PREFIX}geode-builder" ),
> is
> &g

Re: Requirements for running distributed tests

[Jens Deppe]

Hi Alberto,

The images used to run tests on in CI are built here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-images
(you
may see these referred to as 'heavy lifters'). The packer scripts for these
can be found under here:
https://github.com/apache/geode/tree/develop/ci/images

The build model is not pure Concourse as, for every test category (ex.
distributedTest) we programmatically launch one of these 'heavy-lifters',
copy the code over, and then run the tests.

As you've noted, distributed tests are run inside docker containers. This
gives isolation so that there are no port/filesystem/network conflicts when
running tests in parallel. The container used for distributed tests is
built from this Dockerfile:
https://github.com/apache/geode/tree/develop/ci/images/test-container.

Windows tests are not run in parallel as we didn't have success in getting
the parallel dockerization to work consistently; so we only have a subset
of tests which run in 'normal', serial mode.

Hope this helps.
--Jens

On Wed, Jul 17, 2019 at 3:47 AM Alberto Bustamante Reyes
 wrote:

> Hi Geode community,
>
> We are trying to set up a CI loop in our Geode fork. We have started with
> the tests that are run for every pull requests, but we are having problems
> to replicate what is done in the Apache Geode repository, so any help will
> be appreciated.
> We are not using concour, but we are trying to run the same commands that
> are run at the end.
>
> In the case of distributedTests, if we run them we have problems saying
> that there are ports in use, which are not present if we run the tests
> independently ( I mean running for example "geode-core:distributedTest",
> "geode-cq:distributedTest" instead of just "distributedTest"). So we think
> we are missing something regarding the configuration of the VM where the
> tests are executed. We have seen there is a custom image used in google
> cloud (
> --image-family="${IMAGE_FAMILY_PREFIX}${WINDOWS_PREFIX}geode-builder" ), is
> it documented somewhere which are the requirements or configuration of that
> image?
>
> We have seen in the CI configuration (
> https://github.com/apache/geode/blob/develop/ci/pipelines/shared/jinja.variables.yml)
> that the requirement for distributedTests are 96 cpus & 180GB RAM. We can
> use only 24 cpus and 128GB RAM, but we have seen the tests are executed
> using the "dunitParallelForks" parameter to control how many docker
> containers are run in parallel, so we suppose we should modify this
> parameter.
>
> Where can we check how are these containers created and controlled?
>
> Thanks in advance!
>
> Alberto B.
>
>
>