Re: rewrite CI pipeline

[Anthony Baker]

I would not expect to see any differences between openjdk distributions.

Anthony


> On Nov 21, 2022, at 4:34 PM, Sai Boorlagadda  
> wrote:
> 
> !! External Email
> 
> I was thinking it has to do with either JDK or ubuntu. I also tried
> 'temurin'
> and there were different sets of errors. So to see if the devs can shed
> some light on JDK dependency or any prior knowledge on choosing
> bellsoft distribution.
> 
> Sai
> 
> On Mon, 21 Nov 2022 at 16:25, Kirk Lund  wrote:
> 
>> It's also possible that these issues are specific to using OpenJDK 8 or
>> Ubuntu. I thought we were building and testing with CentOS before.
>> 
>> On Mon, Nov 21, 2022 at 4:20 PM Kirk Lund  wrote:
>> 
>>> Looks like membership errors. Membership went through extensive changes
>> to
>>> be modularized as geode-membership, and VMware was still fixing some bugs
>>> in it when I left. These could be really difficult to solve for those of
>> us
>>> who have no experience with the new membership.
>>> 
>>> I wonder if we could engage VMware for a little more help on these
>>> failures before they depart entirely?
>>> 
>>> Last I heard there were also problems with using OpenJDK 8 but I don't
>>> know the details. VMware was using Liberica JDK 8 from Bellsoft. We may
>>> also need VMware to explain what the issue was with OpenJDK 8 so we can
>>> figure out what to do about it.
>>> 
>>> On Mon, Nov 21, 2022 at 3:29 PM Sai Boorlagadda <
>> sai.boorlaga...@gmail.com>
>>> wrote:
>>> 
 Hello devs,
 
 I started a parallel activity to tease out CI work on using ASF jenkins
 and
 also Github actions (though GHA has several issues). I wanted to provide
 some updates on these efforts and seek if others are interested to
 collaborate.
 
 Jenkins - Was waiting for INFRA to create a high level folder[1] to host
 all Geode jobs and have a basic unit test pipeline[2] that runs tests on
 Ubuntu using Oracle JDK 8. While there are failing tests[3] that need
>> some
 help, I am still exploring ways to write pipelines and include multiple
 JDKs into a single JOB, so we can build using 8 while we test using 11.
 
 GHA - While it is super quick and easy to start writing a pipeline[4]
 using
 "matrix and strategy", There are few tests[5] failing consistently using
 Adopt JDK 8 on Ubuntu.
 
 [1] 
 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci-builds.apache.org%2Fjob%2FGeode%2Fdata=05%7C01%7Cbakera%40vmware.com%7C313885015e604ec0189c08dacc217432%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638046741303111474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=BcOk3bhLThh21s0iQAZmes4gab%2B8YpdIlnoVgTIlsb4%3Dreserved=0
 [2]
 
 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2F4abcdc06af536e1188e0f8c432e9b768c175d8c0%2F.jenkins%2FJenkinsfiledata=05%7C01%7Cbakera%40vmware.com%7C313885015e604ec0189c08dacc217432%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638046741303111474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9UvAI7RIV1caJJz70958WqyHNgkkN%2FMihHqONxUKiiw%3Dreserved=0
 [3] 
 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci-builds.apache.org%2Fjob%2FGeode%2Fjob%2Fgeode-develop%2F11%2Fconsoledata=05%7C01%7Cbakera%40vmware.com%7C313885015e604ec0189c08dacc217432%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638046741303111474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Kk1Nj%2FfusbTjMnBLQdpYoJk1mFSGNv0DaLYTmnrNUQE%3Dreserved=0
 [4] 
 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7870%2Ffilesdata=05%7C01%7Cbakera%40vmware.com%7C313885015e604ec0189c08dacc217432%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638046741303267691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=psIl5Jj%2BZHWXfuv1LBj5V5GKbzoy%2FnN9AQFrIjks9Bo%3Dreserved=0
 [5] 
 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Factions%2Fruns%2F3515795079data=05%7C01%7Cbakera%40vmware.com%7C313885015e604ec0189c08dacc217432%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638046741303267691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=JJXdJ%2BQoGOtTdRw7kl8AoFCrilQ7KtCcXS7E6xUJBfU%3Dreserved=0
 
>>> 
>> 
> 
> !! External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: [DRAFT] Geode Board Report for November 9th

[Anthony Baker]

Let’s put this statement in context. It’s not _that_ unusual for some projects 
to have no commits for a month. But is it is very indicative of the state of 
the Geode community given its history of being one of the more active ASF 
projects. As noted in the last board report, project activity declined 
precipitously starting early this summer and is now pretty much stopped 
altogether.

https://medium.com/indeed-engineering/whats-up-asf-using-imhotep-to-understand-project-activity-cdac94e1a68b
https://github.com/apache/geode/graphs/commit-activity

Anthony


On Nov 4, 2022, at 11:42 AM, Dan Smith 
mailto:dasm...@vmware.com.INVALID>> wrote:

There have been no commits since October 10th.

Re: [DRAFT] Geode Board Report for November 9th

[Anthony Baker]

Do you want to add the results of the PMC roll call?

> On Nov 4, 2022, at 11:42 AM, Dan Smith  wrote:
> 
> !! External Email
> 
> In addition to the resolution to terminate the geode project, I think we 
> should file a board report for this quarter with some more details. Here is a 
> draft, let me know what you think.
> 
> ## Description:
> The mission of Apache Geode is the creation and maintenance of software 
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud architectures.
> 
> ## Issues:
> The Geode project has voted to enter the attic, and there is a corresponding
> board resolution on the agenda.
> 
> The two organizations sponsoring contributors have disengaged from the
> community, leaving the project without a critical mass to carry on. We tried
> to recruit some additional contributors and PMC members, but it looks like the
> PMC will not be able to muster a quorum of 3 members going forward. All but
> one of the existing PMC members are either inactive or will be leaving the
> project shortly.
> 
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (6 years ago)
> There are currently 116 committers and 35 PMC members in this project.
> The Committer-to-PMC ratio is roughly 8:3.
> 
> Community changes, past quarter:
> - No new PMC members. Last addition was Alexander Murmann on 2020-03-26.
> - Jakov Varenina was added as committer on 2022-10-10
> - 19 PMC members have left since last quarter
> 
> ## Project Activity:
> 1.15.1 was released on 2022-10-10.
> 
> There have been no commits since October 10th.
> 
> ## Community Health:
> With the exit of the two corporate sponsors there do not seem to be many
> active members left. We attempted to nominate three new PMC members but they
> declined. There was an offer to help with the project from one user in
> response to the attic vote, but even adding that user to the PMC would not
> have reached quorum for the project.
> 
> !! External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: [VOTE] Move geode to the attic

[Anthony Baker]

Regretfully, I am voting +1 to retire the Geode project.

During the PMC roll call and open discussion on dev/user lists, we did not find 
enough PMC volunteers to carry the project forward even at a minimum level. 
While the PMC roster was large the vast majority of the members were either 
inactive, have resigned, or indicated they are contributing on a temporary 
basis only (including myself).

Beyond that, Geode is a significant project with a large codebase and a 
reputation for quality. Keeping the code, libraries, and build system 
up-to-date and CVE-free is no small endeavor. There are tens of thousands of 
tests that will need skilled hands to troubleshoot the inevitable failures and 
flaky results. With only a single commit in October I am not seeing an active 
committer base moving the project forward. This compares to over 120 commits in 
October 2021. I don’t believe this is an anomaly—project activity has 
effectively halted.

I think even if we met the minimum PMC criteria we are only delaying the 
inevitable without active committers.

Anthony


On Nov 2, 2022, at 1:54 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

Any last votes on this? My current count:

Binding Votes:
1 vote to move to the attic (Xiaojian)

Non-binding votes:
2 votes to move to the attic (Donal and Ernie)
1 vote against and an offer to help maintain the project (Rupert)

I'll let the dust settle for another day and then close this vote.

-Dan

From: Xiaojian Zhou 
mailto:zho...@vmware.com.INVALID>>
Sent: Sunday, October 30, 2022 10:51 PM
To: u...@geode.apache.org<mailto:u...@geode.apache.org> 
mailto:u...@geode.apache.org>>; 
dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: [VOTE] Move geode to the attic

!! External Email

Vote to move to attic.

Regards
Xiaojian Zhou, PMC of geode

From: Dan Smith mailto:dasm...@vmware.com>>
Date: Friday, October 28, 2022 at 3:15 PM
To: u...@geode.apache.org<mailto:u...@geode.apache.org> 
mailto:u...@geode.apache.org>>, 
dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: [VOTE] Move geode to the attic
There is still an ongoing discussion on the private@geode list, let's go ahead 
and extend the VOTE deadline until at least Wednesday, November 2.

As Anthony mentioned, only PMC member votes actually count. But all community 
members should feel free to cast their vote and help us reach a consensus. At 
the moment, I count zero PMC votes for or against this proposal.

Thanks,
-Dan

From: rup...@webstersystems.co.uk<mailto:rup...@webstersystems.co.uk> 
mailto:rup...@webstersystems.co.uk>>
Sent: Tuesday, October 25, 2022 12:30 PM
To: u...@geode.apache.org<mailto:u...@geode.apache.org> 
mailto:u...@geode.apache.org>>; 
dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: RE: [VOTE] Move geode to the attic

‼ External Email

Hello, I vote to keep an open source version.
Volunteer for PMC.
Please ping me.
Cheers.

-Original Message-
From: Anthony Baker mailto:bak...@vmware.com>>
Sent: 25 October 2022 18:38
To: dev@geode.apache.org<mailto:dev@geode.apache.org>
Cc: u...@geode.apache.org<mailto:u...@geode.apache.org>
Subject: Re: [VOTE] Move geode to the attic

I added the user@ list for visibility.

I believe the purpose of taking a VOTE here is to look for community consensus 
on this idea and perhaps find new people interested in carrying the project 
forward. The votes of the existing PMC members are the ones that count, just 
like for a release. Quoting from [1]:

"There are two expected mechanisms by which a project may enter the Attic. 
Either the managing Project Management Committee (PMC) decides it would like to 
move the project, or The Apache Software Foundation's board dissolves the PMC 
and chooses to move the project.”

And

"Projects whose PMC are unable to muster 3 votes for a release, who have no 
active committers or are unable to fulfill their reporting duties to the board 
are all good candidates for the Attic.”

I’m holding my vote for now. I would vote +1 if I don’t see sufficient ability 
for the PMC to carry the project.


Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fdata=05%7C01%7Cdasmith%40vmware.com%7C37d98042d8ef49984ade08dabb0402fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638027923164232642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=gxqKYTayLzJG0r%2B4BT2ZfHjkgPN917aElv3qbsfqwoU%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fdata=05%7C01%7Cdasmith%40vmware.com%7C37d98042d8ef49984ade08dabb0402fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638027923164

Re: [VOTE] Move geode to the attic

[Anthony Baker]

I added the user@ list for visibility.

I believe the purpose of taking a VOTE here is to look for community consensus 
on this idea and perhaps find new people interested in carrying the project 
forward. The votes of the existing PMC members are the ones that count, just 
like for a release. Quoting from [1]:

"There are two expected mechanisms by which a project may enter the Attic. 
Either the managing Project Management Committee (PMC) decides it would like to 
move the project, or The Apache Software Foundation's board dissolves the PMC 
and chooses to move the project.”

And

"Projects whose PMC are unable to muster 3 votes for a release, who have no 
active committers or are unable to fulfill their reporting duties to the board 
are all good candidates for the Attic.”

I’m holding my vote for now. I would vote +1 if I don’t see sufficient ability 
for the PMC to carry the project.


Anthony

[1] https://attic.apache.org/


> On Oct 24, 2022, at 10:51 AM, Dan Smith  wrote:
> 
> ⚠ External Email
> 
> Hi folks,
> 
> Last week we discussed moving Geode to the attic [1]. I'm sad to find us at 
> this point. But given that we will soon be without three active members to 
> form a functional PMC, it's time to put this to a vote. I propose we dissolve 
> the Geode PMC and move the Geode project to the attic.
> 
> Please cast your vote by Monday Oct 31st.
> 
> Thanks,
> -Dan
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fbx6t1cppbj7nmfjnf9gtcqjljp8bdf0ydata=05%7C01%7Cbakera%40vmware.com%7Ca3d22ca7f0a44eed05cd08dab5e879e4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638022307326356402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tRdT0pfZ5Q2hjRPsQ50ih9n%2BCczTUPoGbIXTgX26ENs%3Dreserved=0
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: [DISCUSS] Move geode to the attic

[Anthony Baker]

Bumping this discussion onto the user@ list for visibility.

> On Oct 18, 2022, at 11:49 AM, Owen Nichols  
> wrote:
> 
> ⚠ External Email
> 
> Once moved to the attic, it sounds like:
> 
>  *   The geode github repo would become read-only (but remain world-readable 
> in perpetuity).
>  *   Geode would no longer be available for download on the geode download 
> site or mirrors (but still available in releases tab in github).
>  *   Geode maven artifacts would remain available from mavencentral.
>  *   Geode homebrew formula would no longer be installable.
>  *   Unsure whether apachegeode/geode docker image would remain available?
>  *   Geode confluence wiki would become read-only.
>  *   It sound like the user mailing list may be able to remain active?
> 
> Since no further release are possible without at least 3 active PMC members 
> to provide the requisite 3 approving PMC votes, the Attic sounds like the 
> best possible way to leave things.
> 
> From: Dan Smith 
> Date: Tuesday, October 18, 2022 at 11:12 AM
> To: dev@geode.apache.org 
> Subject: [DISCUSS] Move geode to the attic
> ⚠ External Email
> 
> Hi folks,
> 
> Unfortunately, it is time to consider moving Geode to the Apache attic. After 
> VMware's announcement that it will stop contributing to Geode, we've tried in 
> the last couple months to recruit additional contributors to continue 
> supporting the project [1]. However, this last week there was a PMC role call 
> on the private list and it appears we will only have one active PMC member 
> after the VMware folks completely leave.
> 
> I think at this point the responsible thing to do is dissolve the Geode PMC 
> and move the project to the attic, unless some new contributors suddenly show 
> up. We need a minimum of 3 PMC members to keep the project viable.
> 
> This is not yet a vote. I'll let this discussion run this week and start a 
> vote next week. I believe even if we vote to dissolve the project and move to 
> the attic, the soonest that process would start would be after the November 
> board meeting [2].
> 
> Thanks,
> -Dan
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fd88byb42gm5wplzqwkgywg3w9vtj64drdata=05%7C01%7Cbakera%40vmware.com%7C7c3e8f87539d48afa83408dab1399403%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017158136565386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=i%2F5d4tbX1dlG79Utb92vyg9R%2BXE87QaPOMgAWEshFDA%3Dreserved=0
> [2] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2Fprocess.htmldata=05%7C01%7Cbakera%40vmware.com%7C7c3e8f87539d48afa83408dab1399403%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638017158136565386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FC6THZfQgattsCrwSXGudfUVziKTK819eTXanqWm3XE%3Dreserved=0
> 
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

[RESULT][VOTE] Apache Geode 1.15.1.RC1

[Anthony Baker]

The vote passes with 3 binding +1 votes.

@Owen - could you help finalize the release?

Thanks,
Anthony

Re: [VOTE] Apache Geode 1.15.1.RC1

[Anthony Baker]

I’m going to go ahead and close the vote since we have sufficient review.

Anthony


On Oct 6, 2022, at 6:15 AM, Anthony Baker 
mailto:bak...@vmware.com.INVALID>> wrote:

⚠ External Email

Mario, do you plan to close the vote soon?

Anthony


---
Sent from Workspace ONE 
Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=GnAR9qsIgnAuVtow4m%2B7%2B0EMWIbOgY5AFEnTaYowrI8%3Dreserved=0>

On September 29, 2022 at 5:36:39 AM PDT, Mario Kevo 
mailto:mario.k...@est.tech>> wrote:
⚠ External Email

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.15.1.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 Tue, Oct 04 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.1data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MWU6LS0Bes3QwZANKjVVXpxcOYACYihe21mNOwI5BLI%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.1.RC1%2Fdata=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=U4WaP8H6V7c40G019WpKK87jcr1V5JmiTIKSOfp9Zfc%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yD2fvhCKvckhjKreQt12eyGgvlJRRUnm7OQiO0dRGc4%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VRjDB6ibpSotXHa%2FLzt8m1%2FEQ9Ua%2BUVFIT7zGpGRCXw%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=HfUQQaPosQP%2F6eMg5%2B1G%2FG60fC0TdRHnkOVcUO%2FRfkA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=aoImCwk5DjnlDhzcD5de0O%2Fiy11nk3F1RennS7DxAIQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=z%2Fb6cEQGZxFFjlAIT91bJHaKRme8Tvj%2FdIViwGRKp9g%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e4890cb4708daa79ceb1d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638006589651335687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=03lP1saAelE7erO5uAcbPMWadX2wpGVG4Rp6hFh52l0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-rcdata=05%7C01%7Cbakera%40vmware.com%7Cec42b5f6b84e48

Re: https://concourse.apachegeode-ci.info/ is shutting down

[Anthony Baker]

Sounds like good idea to me! You might check with ASF Infra to see their views 
on GF actions. If you can find another project that has already done this, it’s 
a lot easier.

Anthony


> On Oct 7, 2022, at 8:24 AM, Mario Salazar de Torres 
>  wrote:
> 
> ⚠ External Email
> 
> Hi everyone,
> 
> Regarding this, some time ago Michael Oleske and myself were looking into 
> implementing GitHub Actions as the de-facto CI solution for Geode Native. Now 
> Concourse CI is not available anymore, I'd like to propose GH actions as the 
> alternative, at least for Geode Native.
> I have been preparing the pipelines and there are still some details to work 
> out, but it looks promising, you can check I.E this run: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNordix%2Fgeode-native%2Factions%2Fruns%2F3176127664data=05%7C01%7Cbakera%40vmware.com%7Cb56097d700494fe038ed08daa8780af5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007530780766603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nqlkCsAkO3nu2u4Y6JFhrqb%2FPXpwWcve3%2BymvBySG74%3Dreserved=0
> 
> So, I wanted to ask what you think about this proposal.
> My idea is if nobody presents any arguments against it by next Wednesday, 
> 12th of October, I'll start to work on it.
> 
> Also, when you say ASG-hosted CIs, you mean like whole CI solutions right? Do 
> you happen to know if they provide hardware resources on its own? I mention 
> it because it would be ideal to connect GH actions to that hardware so 
> executions would take less time.
> 
> /Mario
> 
> From: Anthony Baker 
> Sent: Thursday, September 29, 2022 8:32 PM
> To: dev@geode.apache.org 
> Subject: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fdata=05%7C01%7Cbakera%40vmware.com%7Cb56097d700494fe038ed08daa8780af5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007530780766603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=E9K02WqeEXh84BUbxuQzPYBbrKAYtDkIvr1Velz%2BL3k%3Dreserved=0
>  is shutting down
> 
> At 3pm PST today the 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fdata=05%7C01%7Cbakera%40vmware.com%7Cb56097d700494fe038ed08daa8780af5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007530780766603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=E9K02WqeEXh84BUbxuQzPYBbrKAYtDkIvr1Velz%2BL3k%3Dreserved=0
>  site will be shutting down. Apologies for the short notice, I just received 
> this information today.
> 
> As discussed on other threads, there are ASF-hosted CI alternatives. I’m 
> happy to point any volunteers in the right direction.
> 
> 
> Anthony
> 
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: [VOTE] Apache Geode 1.15.1.RC1

[Anthony Baker]

Mario, do you plan to close the vote soon?

Anthony


---
Sent from Workspace ONE Boxer

On September 29, 2022 at 5:36:39 AM PDT, Mario Kevo  wrote:
⚠ External Email

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.15.1.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 Tue, Oct 04 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.1data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=msPdhamiWPQWqT%2FaN8A2eYSREoITaZGc0owe4uITO3k%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.1.RC1%2Fdata=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=i5ODdTMztwDAgxNSgp5cZ62FmksSmpLLqGjzkHWvOCk%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=odkkXDzUMui%2Br3qynSoo4vmu2Tr8btRIGSNMM%2Br3zJs%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ILeISQsJsNypbdIQ7K89ory7i049rdC1xfOMQ3wvk7s%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6MymwIiFkorVQyO%2F8jWHog%2FoxBGLhAROw3bz6ZqUsos%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=jHB%2BGjGkTqyMPVvNK3qmvKIVHcRdMo5%2FGQtsE3%2FXDOc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=l0wkimdj0bVqGKCJOFhaC2VLyqnajmPLf3QvlMNScd8%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5aNhuCIa1rpFhggm7iTh5YSpu8qj2CXRF1R0fpgV2VA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-rcdata=05%7C01%7Cbakera%40vmware.com%7Cfaf8de0a419f415e029408daa2174008%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000517996256852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ianNO17gCWpThsTIiGx2QVAKQkugRARoQHSQwPFvKUE%3Dreserved=0

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

Re: [VOTE] Apache Geode 1.15.1.RC1

[Anthony Baker]

+1

Reviewed source for binaries
Built from source
Ran tests with source and binary builds

Anthony




> On Sep 30, 2022, at 3:21 PM, Dan Smith  wrote:
> 
> ⚠ External Email
> 
> +1 - Ran dev-tools/release-testing/smoketest_rc.sh
> 
> -Dan
> 
> From: Mario Kevo 
> Sent: Thursday, September 29, 2022 5:36 AM
> To: dev@geode.apache.org 
> Subject: [VOTE] Apache Geode 1.15.1.RC1
> 
> ⚠ External Email
> 
> Hello Geode Dev Community,
> 
> This is a release candidate for Apache Geode version 1.15.1.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 Tue, Oct 04 2022.
> 
> Please note that we are voting upon the source tag:
> rel/v1.15.1.RC1
> 
> Release notes:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.15.1data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427513622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hSCHGk0E40DZ7j78Md6BoBCJNnSmaU9pveaOFQLeLqo%3Dreserved=0
> 
> Source and binary distributions:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.15.1.RC1%2Fdata=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mY4lnlJQI%2FSNSb0zsh4ItlsPbeFicrQ6TXFWfbO43kE%3Dreserved=0
> 
> Maven staging repo:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mSqZGxOo%2FvJrsO9meBpvs%2FdQtjy%2FwwGdC47ps8ti8F8%3Dreserved=0
> 
> GitHub:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9Z2n4u4Bl5GHiPT2lk5jJdaTH5f4KFHtXKZIxJkt0oQ%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=s%2Fe7KKYL2DMPIHlPS4V2HkD4swo19kw5npvzOorPJmo%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ONBsKzsafV04B02Qe2iNbXIPONTBJx6HLzWlMCIiyxA%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.15.1.RC1data=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2BVyak4x9mkAJIuDtampfjfhSvIcCmqFUr0e6zH2ox0Y%3Dreserved=0
> 
> Pipelines:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-maindata=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0h2gklOfaZcS4UkEqHlghNLEEqEf%2Blhsul80NCdnK2M%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-15-rcdata=05%7C01%7Cbakera%40vmware.com%7Cb73823916fde47ef42d008daa3323cfc%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638001733427670822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xHjyJ7UoxIHRxHvm%2FRabeI7F1pMfns%2BCPjl5DS3InfQ%3Dreserved=0
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
> 

https://concourse.apachegeode-ci.info/ is shutting down

[Anthony Baker]

At 3pm PST today the https://concourse.apachegeode-ci.info/ site will be 
shutting down. Apologies for the short notice, I just received this information 
today.

As discussed on other threads, there are ASF-hosted CI alternatives. I’m happy 
to point any volunteers in the right direction.


Anthony

Re: Release manager permissions

[Anthony Baker]

A few ASF links worth looking into:

https://infra.apache.org/services.html#build
https://builds.apache.org/
https://infra.apache.org/hosting-external-agent.html


On Sep 27, 2022, at 1:45 PM, Owen Nichols 
mailto:onich...@vmware.com.INVALID>> wrote:

⚠ External Email

Hi Mario, a basic concourse installation[1] needs a database (e.g. Postgres), 
the concourse web service, and 1 or more concourse workers.  A secrets store 
like Vault is also recommended.  These don’t have to be especially beefy (if 
hosting in GCP, something like gcp n2-standard-4 is fine).  Baseline operating 
costs for a concourse deployment could range from $100-1000 per month depending 
on what hardware or cloud provider is used and how many workers are used.

Geode pipeline jobs spawn additional instances in GCP to actually execute the 
tests.  The CPU, RAM, and disk specs for these machines are defined in geode/ci 
[2] and some jobs use as many as 96 CPUs for parallel execution.  In total, 
these spot instances cost on the order of $25 per PR commit + $75 per PR merged.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse-ci.org%2Finstall.htmldata=05%7C01%7Cbakera%40vmware.com%7Ca9d8531cb8cd48365a8408daa0c93d0a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637999083443746661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=3yeEMQS6gzEq%2Fu08d3L3AyJ2nrT0PhUxGQ9mk9svxN4%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fci%2Fpipelines%2Fshared%2Fjinja.variables.ymldata=05%7C01%7Cbakera%40vmware.com%7Ca9d8531cb8cd48365a8408daa0c93d0a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637999083443746661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=jualU0witOHsiGeaC3MTTGYj5aN9im8cLSfwJjps2wc%3Dreserved=0

From: Mario Kevo mailto:mario.k...@est.tech>>
Date: Tuesday, September 27, 2022 at 6:41 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Odg: Release manager permissions
⚠ External Email

Hi Anthony,

I have a question regarding CI.
I saw the file in the geode repo with some values for machines on which tests 
are executed. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fe2ac1113f8f6819095785be556bef8e080ab6988%2Fci%2Fpipelines%2Fshared%2Fjinja.variables.yml%23L92data=05%7C01%7Cbakera%40vmware.com%7Ca9d8531cb8cd48365a8408daa0c93d0a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637999083443746661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=B89hP4xyW3ncAGoM%2Fm%2FTPXrevROM%2FyNjJOSA8ZglVUU%3Dreserved=0

So I have a question, what is the setup now that it is used on Concourse CI?
Do you have one or more machines(and how many) so tests can be executed in 
parallel? How many CPUs, RAM and disk sizes are used for them?

Thanks and BR,
Mario

Šalje: Alberto Gomez mailto:alberto.go...@est.tech>>
Poslano: 27. rujna 2022. 13:12
Prima: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Predmet: Re: Release manager permissions

Hi,

Do you know if any company has offered to sponsor the CI pipelines? What would 
it take for such a company besides paying the bills? Would a migration be 
needed?

Regarding the old ASF Jenkins jobs, my understanding is that they would offer 
the same CI functionality as we have today, but they would be run on ASF 
provided resources which would most likely make the time to get results longer 
and less predictable. Is that correct?


Thanks,

Alberto
____
From: Anthony Baker 
mailto:bak...@vmware.com.INVALID>>
Sent: Friday, September 23, 2022 8:15 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: Release manager permissions

Just a reminder to all: we need to find an alternative to the VMware-sponsored 
CI pipelines currently in use. Any ideas? Should we try to resurrect the old 
ASF Jenkins jobs?

Anthony

On Sep 23, 2022, at 3:26 AM, Mario Kevo 
mailto:mario.k...@est.tech>> wrote:

⚠ External Email

Hi devs,

I need the following permissions for the release manager:

*   bulk modification permission on Apache Geode JIRA
*   permission to deploy pipelines to Geode CI
*   Docker Hub credentials with permission to upload Apache Geode to Docker Hub

username: mkevo
mail: mk...@apache.org<mailto:mk...@apache.org>

Can someone give me these permissions, so I can start building a new patch 
release?

Thanks and BR,
Mario



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

Re: Release manager permissions

[Anthony Baker]

BTW, you should now have access to DockerHub and bulk change in JIRA. Anything 
else you need to create the 1.15.1 release candidate?

Anthony


> On Sep 26, 2022, at 8:55 AM, Anthony Baker  wrote:
> 
> ⚠ External Email
> 
> Looks like Docker is limiting access. I’ll need to rotate some people from 
> the Docker org.
> 
> Anthony
> 
> 
>> On Sep 25, 2022, at 11:42 PM, Mario Kevo  wrote:
>> 
>> ⚠ External Email
>> 
>> Hi Anthony,
>> 
>> I still don't have permission for Concourse. I logged in with a GitHub 
>> account and saw that I'm not authorized to run jobs.
>> Username: mkevo
>> 
>> The username for Docker Hub is the same: mkevo.
>> 
>> Thanks,
>> Mario
>> 
>> 
>> Šalje: Anthony Baker 
>> Poslano: 23. rujna 2022. 20:15
>> Prima: dev@geode.apache.org 
>> Predmet: Re: Release manager permissions
>> 
>> Just a reminder to all: we need to find an alternative to the 
>> VMware-sponsored CI pipelines currently in use. Any ideas? Should we try to 
>> resurrect the old ASF Jenkins jobs?
>> 
>> Anthony
>> 
>>> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
>>> 
>>> ⚠ External Email
>>> 
>>> Hi devs,
>>> 
>>> I need the following permissions for the release manager:
>>> 
>>> *   bulk modification permission on Apache Geode JIRA
>>> *   permission to deploy pipelines to Geode CI
>>> *   Docker Hub credentials with permission to upload Apache Geode to Docker 
>>> Hub
>>> 
>>> username: mkevo
>>> mail: mk...@apache.org
>>> 
>>> Can someone give me these permissions, so I can start building a new patch 
>>> release?
>>> 
>>> Thanks and BR,
>>> Mario
>>> 
>>> 
>>> 
>>> ⚠ External Email: This email originated from outside of the organization. 
>>> Do not click links or open attachments unless you recognize the sender.
>> 
> 

[ANNOUNCE] New project members

[Anthony Baker]

The Geode PMC is pleased to welcome Mario Kevo and Jakov Varenina as new PMC 
members. Jakov has also accepted an invitation to become a Committer.

Welcome!

As a reminder to all, ASF project roles [1] are based on earned merit, or 
contributions to a project. These contributions can take many forms from code 
to documentation to answering questions or content development. If you are 
interested in contributing to Geode, please ask!

Thanks,
Anthony

[1] https://www.apache.org/foundation/how-it-works.html#roles

Re: Release manager permissions

[Anthony Baker]

Hi Alberto,

All the existing concourse CI scripts are in GitHub [1] so it’s definitely 
possible for someone to stand up a Concourse deployment and use the current 
pipelines. I assume there are some domain names and certificates that may need 
to be transferred as well. This has worked well but could be a lot of work and 
learning to get started. Of course there are other tools as well. To date, I’m 
not aware of any interest from potential CI sponsors.

My experience with ASF resources is fairly out of date. When we used this back 
in the day, the testing took quite some time. I believe we had a daily job and 
release jobs. Perhaps the Jenkins tooling has been updated to allow more 
“pipeline-like” test jobs.

Anthony



[1] https://github.com/apache/geode/tree/develop/ci


On Sep 27, 2022, at 4:12 AM, Alberto Gomez 
mailto:alberto.go...@est.tech>> wrote:

⚠ External Email

Hi,

Do you know if any company has offered to sponsor the CI pipelines? What would 
it take for such a company besides paying the bills? Would a migration be 
needed?

Regarding the old ASF Jenkins jobs, my understanding is that they would offer 
the same CI functionality as we have today, but they would be run on ASF 
provided resources which would most likely make the time to get results longer 
and less predictable. Is that correct?


Thanks,

Alberto

From: Anthony Baker 
mailto:bak...@vmware.com.INVALID>>
Sent: Friday, September 23, 2022 8:15 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
mailto:dev@geode.apache.org>>
Subject: Re: Release manager permissions

Just a reminder to all: we need to find an alternative to the VMware-sponsored 
CI pipelines currently in use. Any ideas? Should we try to resurrect the old 
ASF Jenkins jobs?

Anthony

On Sep 23, 2022, at 3:26 AM, Mario Kevo 
mailto:mario.k...@est.tech>> wrote:

⚠ External Email

Hi devs,

I need the following permissions for the release manager:

*   bulk modification permission on Apache Geode JIRA
*   permission to deploy pipelines to Geode CI
*   Docker Hub credentials with permission to upload Apache Geode to Docker Hub

username: mkevo
mail: mk...@apache.org<mailto:mk...@apache.org>

Can someone give me these permissions, so I can start building a new patch 
release?

Thanks and BR,
Mario



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

Re: Odg: Release manager permissions

[Anthony Baker]

Looks like Docker is limiting access. I’ll need to rotate some people from the 
Docker org.

Anthony


> On Sep 25, 2022, at 11:42 PM, Mario Kevo  wrote:
> 
> ⚠ External Email
> 
> Hi Anthony,
> 
> I still don't have permission for Concourse. I logged in with a GitHub 
> account and saw that I'm not authorized to run jobs.
> Username: mkevo
> 
> The username for Docker Hub is the same: mkevo.
> 
> Thanks,
> Mario
> 
> ____
> Šalje: Anthony Baker 
> Poslano: 23. rujna 2022. 20:15
> Prima: dev@geode.apache.org 
> Predmet: Re: Release manager permissions
> 
> Just a reminder to all: we need to find an alternative to the 
> VMware-sponsored CI pipelines currently in use. Any ideas? Should we try to 
> resurrect the old ASF Jenkins jobs?
> 
> Anthony
> 
>> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
>> 
>> ⚠ External Email
>> 
>> Hi devs,
>> 
>> I need the following permissions for the release manager:
>> 
>> *   bulk modification permission on Apache Geode JIRA
>> *   permission to deploy pipelines to Geode CI
>> *   Docker Hub credentials with permission to upload Apache Geode to Docker 
>> Hub
>> 
>> username: mkevo
>> mail: mk...@apache.org
>> 
>> Can someone give me these permissions, so I can start building a new patch 
>> release?
>> 
>> Thanks and BR,
>> Mario
>> 
>> 
>> 
>> ⚠ External Email: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you recognize the sender.
> 

Re: Release manager permissions

[Anthony Baker]

Just a reminder to all: we need to find an alternative to the VMware-sponsored 
CI pipelines currently in use. Any ideas? Should we try to resurrect the old 
ASF Jenkins jobs?

Anthony

> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
> 
> ⚠ External Email
> 
> Hi devs,
> 
> I need the following permissions for the release manager:
> 
>  *   bulk modification permission on Apache Geode JIRA
>  *   permission to deploy pipelines to Geode CI
>  *   Docker Hub credentials with permission to upload Apache Geode to Docker 
> Hub
> 
> username: mkevo
> mail: mk...@apache.org
> 
> Can someone give me these permissions, so I can start building a new patch 
> release?
> 
> Thanks and BR,
> Mario
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: Release manager permissions

[Anthony Baker]

I updated your JIRA permission, please check. What is your DockerHub username?

Anthony


> On Sep 23, 2022, at 3:26 AM, Mario Kevo  wrote:
> 
> ⚠ External Email
> 
> Hi devs,
> 
> I need the following permissions for the release manager:
> 
>  *   bulk modification permission on Apache Geode JIRA
>  *   permission to deploy pipelines to Geode CI
>  *   Docker Hub credentials with permission to upload Apache Geode to Docker 
> Hub
> 
> username: mkevo
> mail: mk...@apache.org
> 
> Can someone give me these permissions, so I can start building a new patch 
> release?
> 
> Thanks and BR,
> Mario
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: Apache Geode 1.15.1 patch version

[Anthony Baker]

ection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10323data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eMNydE%2B0S1xYSuloD5et0a%2FqwbuzF%2BeZMJ7%2FCGL9fIs%3Dreserved=0>
> GEODE-10323<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10323data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eMNydE%2B0S1xYSuloD5et0a%2FqwbuzF%2BeZMJ7%2FCGL9fIs%3Dreserved=0>
> 
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: 
> expected:<100> but 
> was:<1048576><https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10323data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eMNydE%2B0S1xYSuloD5et0a%2FqwbuzF%2BeZMJ7%2FCGL9fIs%3Dreserved=0>
> 
> [Bug] 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10155data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yNURKPYY4kVadko1pkamzSgKtBoZtvfJdmD8RXrDP9M%3Dreserved=0>
> GEODE-10155<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10155data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yNURKPYY4kVadko1pkamzSgKtBoZtvfJdmD8RXrDP9M%3Dreserved=0>
> 
> ServerConnection thread hangs when client function execution 
> times-out<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10155data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yNURKPYY4kVadko1pkamzSgKtBoZtvfJdmD8RXrDP9M%3Dreserved=0>
> 
> [Improvement] 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10076data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188408298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=vt%2BFOMtOjHKbScV5NYFvjGa5ynZKh3DAwebTVOL6NcA%3Dreserved=0>
> GEODE-10076<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10076data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188564545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cuLFYM1cyE4S%2FoqSGla9W%2B40NyXc%2FyQ2ks87qWJDYQs%3Dreserved=0>
> 
> Fix string codepoint 
> detection<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10076data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188564545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cuLFYM1cyE4S%2FoqSGla9W%2B40NyXc%2FyQ2ks87qWJDYQs%3Dreserved=0>
> 
> BR,
> 
> Alberto
> 
> From: Anthony Baker 
> Sent: Friday, September 9, 2022 8:14 PM
> To: dev@geode.apache.org 
> Cc: Weijie Xu M 
> Subject: Re: Apache Geode 1.15.1 patch version
> 
> Thanks Mario. I removed some entries from the list that didn’t seem relevant 
> to a small patch release. I think previously Xu Weijie volunteered to look at 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10415data=05%7C01%7Cbakera%40vmware.com%7Ce8179323a2ac46241d7e08da97137b34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637988407188564545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=g%2FlWHI6MHgfBNqklkOBQYOAKJL

Re: Apache Geode 1.15.1 patch version

[Anthony Baker]

Thanks Mario. I removed some entries from the list that didn’t seem relevant to 
a small patch release. I think previously Xu Weijie volunteered to look at 
https://issues.apache.org/jira/browse/GEODE-10415.

Anthony


On Sep 8, 2022, at 11:20 PM, Mario Kevo 
mailto:mario.k...@est.tech>> wrote:

⚠ External Email

Hi all,

I'm going to build a new patch version of the Geode.
There is a list of tasks that are declared to be fixed in 1.15.1. As they are 
already assigned, please can the assignee provide a fix for this so we can move 
on? 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fprojects%2FGEODE%2Fversions%2F12351801data=05%7C01%7Cbakera%40vmware.com%7Cb682687cff424bd66c4f08da922b68c9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637983012385132654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=zyj0QD8xHMKWlB92DRlVsZg97ay4Rszqlist8Nut5J0%3Dreserved=0

Also, there is one blocker that will be good to introduce to this release, if 
it is okay for all of you. 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10415data=05%7C01%7Cbakera%40vmware.com%7Cb682687cff424bd66c4f08da922b68c9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637983012385289006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=lhY3UUTY36WFsktv5hjhIH31I7gJW0F94ipJL0ZgKYU%3Dreserved=0

Please suggest if you have some more tickets that are critical and should be 
backported to this release, so we can get an opinion of the community on that 
before releasing the new version.

Thanks and BR,
Mario




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

Re: Release manager for 1.15.1?

[Anthony Baker]

Thanks Rupert!  Since Rupert is not a committer, is anyone available to help 
him learn the ropes?

Anthony


> On Sep 6, 2022, at 11:51 AM, rup...@webstersystems.co.uk wrote:
> 
> ⚠ External Email
> 
> Hi Anthony,
> 
> 
> 
> I’m interested to help out on the Geode 1.15.1 Release Manager.
> 
> I can make time later this week 
> 
> 
> 
> Thanks, kind regards,
> 
> Rupert
> 
> 
> 
> Webster Systems Ltd
> 
> Kingsdon Nursery Garden
> 
> Kingsdon, Somerton, Somerset, TA11 7LE, UK
> 
> Tel: 07740 289100
> 
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webstersystems.co.uk%2Fdata=05%7C01%7Cbakera%40vmware.com%7C057ce4514a024a2f93bb08da90391317%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872145197027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=f4%2BIdvol%2BolysK5XYg0EWVvrJWkVZ2wa6v83ltlIB04%3Dreserved=0>
>  
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webstersystems.co.uk%2Fdata=05%7C01%7Cbakera%40vmware.com%7C057ce4514a024a2f93bb08da90391317%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872145197027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=f4%2BIdvol%2BolysK5XYg0EWVvrJWkVZ2wa6v83ltlIB04%3Dreserved=0
> 
> UK Registered No: 6517977
> 
> 
> 
> -Original Message-
> 
> From: Anthony Baker < <mailto:bak...@vmware.com> bak...@vmware.com>
> 
> Sent: 02 September 2022 17:28
> 
> To:  <mailto:dev@geode.apache.org> dev@geode.apache.org
> 
> Cc:  <mailto:u...@geode.apache.org> u...@geode.apache.org
> 
> Subject: Release manager for 1.15.1?
> 
> 
> 
> This email has reached the company via an external source.
> 
> 
> 
> Please be cautious opening any attachments or links.
> 
> 
> 
> 
> 
> Hi all,
> 
> 
> 
> We need to ship a new Geode 1.15.1 patch to fix a few issues. Part of the 
> Geode and ASF release process is identify a Release Manager to collect the 
> changes, prepare a release candidate, and publish the release binaries. The 
> good news is, we have a well-vetted set of scripts and instructions [1] to 
> automate this and make it super easy for first timers to go through the 
> process.
> 
> 
> 
> Anyone want to volunteer? We would like to start this process next week (Sept 
> 6).
> 
> 
> 
> Thanks,
> 
> Anthony
> 
> 
> 
> [1]  
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FReleasing%2BApache%2BGeodedata=05%7C01%7Cbakera%40vmware.com%7C057ce4514a024a2f93bb08da90391317%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872145197027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Zre7FG6OaAJqLyl8sP%2FraMR0ammRDnjarFRMYOXeiVg%3Dreserved=0>
>  
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FReleasing%2BApache%2BGeodedata=05%7C01%7Cbakera%40vmware.com%7C057ce4514a024a2f93bb08da90391317%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637980872145197027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Zre7FG6OaAJqLyl8sP%2FraMR0ammRDnjarFRMYOXeiVg%3Dreserved=0
> 
> 
> 
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: [DISCUSS] Opportunities to contribute

[Anthony Baker]

Hi Weijie,

Please take a look at [1] for instructions on bumping dependencies. Please ask 
if you need any help.

Thanks,
Anthony

[1] https://github.com/apache/geode/tree/develop/dev-tools/dependencies


On Sep 6, 2022, at 5:17 AM, Weijie Xu M 
mailto:weijie.m...@est.tech>> wrote:

⚠ External Email

Hi Anthony,

 I'm Weijie from China.
 I want participant release for v1.15.1.
 Is the task I need do that bump the dependency?
 Thanks.

BRs/Xu Weijie

-Original Message-
From: Anthony Baker mailto:bak...@vmware.com>>
Sent: Wednesday, August 31, 2022 10:44 PM
To: dev@geode.apache.org<mailto:dev@geode.apache.org>; 
u...@geode.apache.org<mailto:u...@geode.apache.org>
Subject: [DISCUSS] Opportunities to contribute

Geode community,

I want to inform you of some upcoming changes and opportunities. If you have 
been thinking about contributing to the Geode project, this is a great time to 
jump in and get started.

Many of us in the Geode community are employed by VMware. While each of us 
participates and earns merit as individuals (following the Apache Way), VMware 
has decided to focus its efforts on the commercial GemFire product. Practically 
speaking, this means that many of the most active members of the Geode 
community will be much less involved going forward.

As with any change, this leads to new opportunities. Here are some ways you can 
contribute:

   • Contributing and reviewing code, documentation, or examples
   • Learning, improving, and operating CI pipelines
   • Participating as a Release Manager for v1.15.1
   • Becoming a Committer or PMC member based on project contributions
   • Publishing educational content such as blogs, videos, or conference 
talks
   • Answering questions on the dev list and internet forums like 
StackOverflow
   • Updating the WIKI or JIRA

Note that Apache considers contributions in ALL forms as earning merit as a 
committer. You don’t need to be an expert on Partitioned Region replication 
code to become a committer.

VMware remains a strong proponent of open source software and the Apache 
Software Foundation. VMware is committed to actively supporting an orderly and 
responsible transition to enable other members of the community to take the 
project forward.

I know many of you have contributed greatly from the early days of incubation, 
through graduation, and all the releases up until now. I want to personally 
thank you for those efforts whether in documentation, bug reports, websites, 
discussions, feature proposals, or code submissions.

Please let me know your thoughts on this change and any ideas you have. If you 
would like to contribute, please shout out and ask questions! There are many 
people ready to provide mentoring and answer questions.

Thanks,




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

Re: Release manager for 1.15.1?

[Anthony Baker]

Note that we will want to bump some dependency versions in this patch release. 
If you would like to contribute this change, instructions can be found at 
https://github.com/apache/geode/tree/develop/dev-tools/dependencies.

Anthony

On Sep 2, 2022, at 9:27 AM, Anthony Baker 
mailto:bak...@vmware.com>> wrote:

Hi all,

We need to ship a new Geode 1.15.1 patch to fix a few issues. Part of the Geode 
and ASF release process is identify a Release Manager to collect the changes, 
prepare a release candidate, and publish the release binaries. The good news 
is, we have a well-vetted set of scripts and instructions [1] to automate this 
and make it super easy for first timers to go through the process.

Anyone want to volunteer? We would like to start this process next week (Sept 
6).

Thanks,
Anthony

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FReleasing%2BApache%2BGeodedata=05%7C01%7Cbakera%40vmware.com%7Cff33d85395934f85e53108da8d001cb0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637977328931761268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=azcyfr1oOxXZ%2Fus5LdXWcAqiiPjIfG8bjACpuB69ZjY%3Dreserved=0

Release manager for 1.15.1?

[Anthony Baker]

Hi all,

We need to ship a new Geode 1.15.1 patch to fix a few issues. Part of the Geode 
and ASF release process is identify a Release Manager to collect the changes, 
prepare a release candidate, and publish the release binaries. The good news 
is, we have a well-vetted set of scripts and instructions [1] to automate this 
and make it super easy for first timers to go through the process.  

Anyone want to volunteer? We would like to start this process next week (Sept 
6).

Thanks,
Anthony

[1] https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode

Re: [DISCUSS] Opportunities to contribute

[Anthony Baker]

Excellent! For these contributions you can just dive in, create the content, 
and publish it yourself. If you have questions feel free to ask on the mailing 
lists. Once your content is published let us know and we can link it 
appropriately.

Here are a few examples:

https://cwiki.apache.org/confluence/display/GEODE/Articles+and+Presentations
https://boglesby-2508.medium.com/

Anthony


On Aug 31, 2022, at 8:35 AM, Amit Hora 
mailto:hora.a...@gmail.com>> wrote:


⚠ External Email

Hi Team,

I have been looking for tgis exact opportunity I would be highly interested in 
contributing towards
- Publishing educational content such as blogs, videos, or conference talks

Kindly guide me how I can get started.

Reagards,
Amit Singh Hora

[DISCUSS] Opportunities to contribute

[Anthony Baker]

Geode community,

I want to inform you of some upcoming changes and opportunities. If you have 
been thinking about contributing to the Geode project, this is a great time to 
jump in and get started.

Many of us in the Geode community are employed by VMware. While each of us 
participates and earns merit as individuals (following the Apache Way), VMware 
has decided to focus its efforts on the commercial GemFire product. Practically 
speaking, this means that many of the most active members of the Geode 
community will be much less involved going forward.

As with any change, this leads to new opportunities. Here are some ways you can 
contribute:

• Contributing and reviewing code, documentation, or examples
• Learning, improving, and operating CI pipelines
• Participating as a Release Manager for v1.15.1
• Becoming a Committer or PMC member based on project contributions
• Publishing educational content such as blogs, videos, or conference 
talks
• Answering questions on the dev list and internet forums like 
StackOverflow
• Updating the WIKI or JIRA 

Note that Apache considers contributions in ALL forms as earning merit as a 
committer. You don’t need to be an expert on Partitioned Region replication 
code to become a committer. 

VMware remains a strong proponent of open source software and the Apache 
Software Foundation. VMware is committed to actively supporting an orderly and 
responsible transition to enable other members of the community to take the 
project forward. 

I know many of you have contributed greatly from the early days of incubation, 
through graduation, and all the releases up until now. I want to personally 
thank you for those efforts whether in documentation, bug reports, websites, 
discussions, feature proposals, or code submissions.

Please let me know your thoughts on this change and any ideas you have. If you 
would like to contribute, please shout out and ask questions! There are many 
people ready to provide mentoring and answer questions.

Thanks,

Re: August board report draft

[Anthony Baker]

Last call for comments.

> On Aug 9, 2022, at 10:34 AM, Anthony Baker  wrote:
> 
> ⚠ External Email
> 
> Here is a draft of the quarterly board report (note that board reports can 
> also be provided off-cycle when needed). Please let me know by EOD Thursday 
> if you have any changes / additions.
> 
> Thanks,
> Anthony
> 
> 
> ## Description:
> The mission of Apache Geode is the creation and maintenance of software 
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud architectures.
> 
> ## Issues:
> There are no issues requiring board attention.
> 
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (6 years ago)
> There are currently 115 committers and 54 PMC members in this project.
> The Committer-to-PMC ratio is roughly 2:1.
> 
> Community changes, past quarter:
> - No new PMC members. Last addition was Donal Evans on 2021-03-22.
> - No new committers. Last addition was Alberto Bustamante on 2021-05-13.
> 
> ## Project Activity:
> Apache Geode completed the release process for 1.15.0. This release fixed 887
> JIRA issues and notably adds support for JDK 17 as well as connection
> re-authentication.
> 
> ## Community Health:
> After the 1.15.0 release was complete, we decided to remove the CODEOWNERS
> review requirement as the implementation imposed an onerous burden and
> significantly slowed down PR review and merging.
> 
> We have seen a significant decline in PR and JIRA activity in July compared
> to prior months/years.
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

August board report draft

[Anthony Baker]

Here is a draft of the quarterly board report (note that board reports can also 
be provided off-cycle when needed). Please let me know by EOD Thursday if you 
have any changes / additions.

Thanks,
Anthony


## Description:
The mission of Apache Geode is the creation and maintenance of software related 
to a data management platform that provides real-time, consistent access to 
data-intensive applications throughout widely distributed cloud architectures.

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache Geode was founded 2016-11-15 (6 years ago)
There are currently 115 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 2:1.

Community changes, past quarter:
- No new PMC members. Last addition was Donal Evans on 2021-03-22.
- No new committers. Last addition was Alberto Bustamante on 2021-05-13.

## Project Activity:
Apache Geode completed the release process for 1.15.0. This release fixed 887
JIRA issues and notably adds support for JDK 17 as well as connection
re-authentication.

## Community Health:
After the 1.15.0 release was complete, we decided to remove the CODEOWNERS 
review requirement as the implementation imposed an onerous burden and
significantly slowed down PR review and merging.

We have seen a significant decline in PR and JIRA activity in July compared 
to prior months/years.

Re: CODEOWNERS? (was Re: Pending PR reviews)

[Anthony Baker]

Consensus on this thread is to move ahead with removing CODEOWNERS requirement 
from PR review.

Thanks,
Anthony


> On Jun 29, 2022, at 4:11 PM, Alexander Murmann  
> wrote:
> 
> ⚠ External Email
> 
> +1 to removing CODEOWNERS. It was a good idea, but isn’t working well, in 
> part due to the way GitHub doesn’t provide enough information to determine 
> who is actually needed for review.
> 
> From: Anthony Baker 
> Date: Wednesday, June 29, 2022 at 9:34 AM
> To: dev@geode.apache.org 
> Subject: CODEOWNERS? (was Re: Pending PR reviews)
> ⚠ External Email
> 
> I realize that this is a thread hijack, but hopefully a useful one. I’ve seen 
> several requests for timely reviews in recent months. I think that the 
> CODEOWNERS goals were important and laudable—directing review requests to 
> those most suited to provide oversight—but the implementation has been 
> problematic. The size, complexity, and interconnectedness of the code base 
> meant that many pull requests tagged not just one expert but just about EVERY 
> expert in the community. This is rather inefficient, to say the least.
> 
> I propose that we revert CODEOWNERS and return to the review-then-commit 
> model requiring at least one +1 vote from a committer. I see Owen has already 
> created a PR [1] for this change.
> 
> Thoughts?
> 
> Anthony
> 
> [1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7820data=05%7C01%7Cbakera%40vmware.com%7C79811d072fc74726126008da5a24ab05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921410800473067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WCbjKRcWfv%2B1iBgkg60xaE1dkBJz4q2RUm36aTBupVE%3Dreserved=0
> 
> 
>> On Jun 28, 2022, at 5:43 AM, Mario Ivanac  wrote:
>> 
>> ⚠ External Email
>> 
>> Hi,
>> 
>> The following PRs:
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7323data=05%7C01%7Cbakera%40vmware.com%7C79811d072fc74726126008da5a24ab05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921410800473067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eWy%2BcIeCFPIKrmtf9ivd02HjsPiArqyo9D0UnYfwBHk%3Dreserved=0
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749data=05%7C01%7Cbakera%40vmware.com%7C79811d072fc74726126008da5a24ab05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921410800473067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9Xhng%2F8o1cRW%2BOJ9g0UeL9Tshjh4B0yVXlRmxIV0wxk%3Dreserved=0
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664data=05%7C01%7Cbakera%40vmware.com%7C79811d072fc74726126008da5a24ab05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637921410800473067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2UjXX1hos4K0nK2D7tqg%2Flr1mBwMtGVZcvKj9QTAlEw%3Dreserved=0
>> 
>> are waiting for review for some time.
>> 
>> 
>> Could code owners review these PRs?
>> 
>> Thanks,
>> Mario
>> 
>> 
>> 
>> ⚠ External Email: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you recognize the sender.

CODEOWNERS? (was Re: Pending PR reviews)

[Anthony Baker]

I realize that this is a thread hijack, but hopefully a useful one. I’ve seen 
several requests for timely reviews in recent months. I think that the 
CODEOWNERS goals were important and laudable—directing review requests to those 
most suited to provide oversight—but the implementation has been problematic. 
The size, complexity, and interconnectedness of the code base meant that many 
pull requests tagged not just one expert but just about EVERY expert in the 
community. This is rather inefficient, to say the least.

I propose that we revert CODEOWNERS and return to the review-then-commit model 
requiring at least one +1 vote from a committer. I see Owen has already created 
a PR [1] for this change.

Thoughts?

Anthony

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


> On Jun 28, 2022, at 5:43 AM, Mario Ivanac  wrote:
> 
> ⚠ External Email
> 
> Hi,
> 
> The following PRs:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7323data=05%7C01%7Cbakera%40vmware.com%7Cac199366a0df4d162f9c08da5903c883%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637920170037751522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=83n%2BAmPDOOZbvqp5RYaW06mFU2Cy0azhyhWoIXnFlGE%3Dreserved=0
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7749data=05%7C01%7Cbakera%40vmware.com%7Cac199366a0df4d162f9c08da5903c883%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637920170037751522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tllDC%2Fs0wdCC5Q49tl%2ByQXP%2FzA%2BQT%2B%2Bd2XknHDYBgXk%3Dreserved=0
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7664data=05%7C01%7Cbakera%40vmware.com%7Cac199366a0df4d162f9c08da5903c883%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637920170037751522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=JBEIgFD59ZP3JtTQ4mIPFHWKUTjFeskfxvSCkW9momw%3Dreserved=0
> 
> are waiting for review for some time.
> 
> 
> Could code owners review these PRs?
> 
> Thanks,
> Mario
> 
> 
> 
> ⚠ 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

[Anthony Baker]

Owen, with all the recent work I think we are in an excellent position to 
resume work on the 1.15 release. While there are a few thing still outstanding, 
let’s go ahead and recut the release branch as of Monday, 2022-05-09. Would you 
be willing to resume release manager duties?

@Everyone - please chime in if you have in-progress work that you want to ship 
with 1.15 (ideally this is labeled in JIRA with “blocks-1.15.0”).

Thanks,
Anthony


> On Mar 16, 2022, at 2:12 PM, Owen Nichols  wrote:
> 
> 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
> 
> 

Re: Unable to run apache geode 1.14.4 instance

[Anthony Baker]

Are there any errors in the locator log?  Did the locator log indicate that the 
locator started successfully?

Anthony


> On Mar 30, 2022, at 7:14 AM, Deepak Dixit  wrote:
> 
> ⚠ External Email
> 
> Hello Dev Team,
> 
> I am facing following issue while starting up Apache Geode 1.14.4 instance
> 
> gfsh>start locator --name=test2 --log-level=ALL --bind-address=127.0.0.1
> 
> Starting a Geode Locator in
> /Users/deepakdixit/Downloads/apache-geode-1.14.4/test2...
> 
> 
> 
> Locator in /Users/deepakdixit/Downloads/apache-geode-1.14.4/test2 on
> 127.0.0.1[10334] as test2 is currently online.
> 
> Process ID: 57112
> 
> Uptime: 12 seconds
> 
> Geode Version: 1.14.4
> 
> Java Version: 1.8.0_322
> 
> Log File: /Users/deepakdixit/Downloads/apache-geode-1.14.4/test2/test2.log
> 
> JVM Arguments: -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false -Dgemfire.log-level=ALL
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> 
> Class-Path:
> /Users/deepakdixit/Downloads/apache-geode-1.14.4/lib/geode-core-1.14.4.jar:/Users/deepakdixit/Downloads/apache-geode-1.14.4/lib/geode-dependencies.jar
> 
> 
> Unable to auto-connect (Security Manager may be enabled). Please use
> "connect --locator=localhost[10334]" to connect Gfsh to the locator.
> 
> 
> Failed to connect; unknown cause: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: error during JRMP connection establishment;
> nested exception is:
> 
> java.io.EOFException]
> 
> 
> Environment:
> MacOS Monterey V12.3
> Java Version openjdk version "1.8.0_322"
> 
> Can someone help to find out the root cause for this?
> 
> 
> 
> --
> From:
> 
> Deepak D Dixit
> deepakdixit2...@gmail.com
> +919028507537
> 
> 
> 
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: Update the build to use Gradle 7.4

[Anthony Baker]

Hi Ryan,

Welcome to Geode and thanks for the contribution!

Anthony


> On Feb 9, 2022, at 7:32 AM, Ryan Gardner  wrote:
> 
> Hello,
> 
> Up-front disclaimer: I'm not a Gradle expert - but I spent a little time
> poking around at what it would take to upgrade the build to go from Gradle
> 6.8 -> Gradle 7.4
> 
> Previous efforts to clean up Gradle 7 deprecation warnings made it fairly
> straightforward - in the end it seems there were only a few changes needed.
> 
> - An internal gradle class for the temporary file creation changed it's
> package location in Gradle 7
> - A couple places had references to the now-removed "compile" classpath and
> needed to be replaced with "compileOnly"
> - Gradle 7 gets upset about tasks that have implicit dependencies between
> them - some of the tasks such as the combined report generation needed to
> have a "dependsOn" added to it
> - The Geode build has a custom version of the "DefaultTaskExecutor" -
> Gradle made some minor changes to the DefaultTaskExecutor in version 7.4. I
> made those same changes in the RepeatedTaskExecutor
> 
> On my local machine the build runs the same as it does on the 6.8 version -
> there are some tests that fail due to bind exceptions.
> 
> I just created a draft pull request - like I mentioned before, I'm not the
> world's leading expert in Gradle so there may be a better way to make some
> of the same kind of changes. I created a draft pull request so that it
> might at least serve as a starting point when someone else wants to take a
> look at this.
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7351data=04%7C01%7Cbakera%40vmware.com%7Cb87399be4fd541cce5a308d9ebe17fab%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637800176013319812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Vu9EguhEg9pFE5Ctiw2%2BkluyGiBVTE23uO5KkEI%2BnrQ%3Dreserved=0
> 
> I didn't see a JIRA issue directly associated with this, it's sort of
> related to GEODE-9161  since
> it gets rid of the deprecation warnings.
> 
> Hope it's helpful,
> 
> Ryan

Re: Proposal: Cut 1.15 release branch from SHA 8f7193c827ee3198ae374101221c02039c70a561

[Anthony Baker]

Fair point, although my hope is that we continually and incrementally improve 
our code base on the /develop branch. Yes, there is an increased cost of back 
porting critical changes to support branches but the tradeoff is worth it IMHO.

Anthony


> On Jan 25, 2022, at 11:18 PM, Owen Nichols  wrote:
> 
> Also to consider, having a large refactor on develop but not support/1.15 
> will increase backporting pain, as many cherry-picks will have merge 
> conflicts that have to be manually "un-refactored". 

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0

[Anthony Baker]

Thanks Dan, makes sense.  I have a “review artifacts for license compliance” on 
my todo list, but not likely to get done before the holidays :-)

Anthony


> On Dec 23, 2021, at 3:01 PM, Dan Smith  wrote:
> 
> Well, I haven't seen any votes on this and it's almost Christmas. Let's table 
> this until next year and I'll send out another vote email.
> 
> -Dan
> 
> On Dec 16, 2021 11:33 AM, Dan Smith  wrote:
> This is related to the earlier discussion about the kafka connector. This 
> code was already linked from the confluent hub, but I want to make sure we're 
> in compliance with the apache release policy.
> 
> To create this release, I took the source code and binaries Naba mentioned 
> and compared them with the rel/1.1.0 source tag and the results of building 
> that tag. They were identical except for the build date in the metadata.json 
> file for the binary.
> 
> I added gpg and sha256sum signatures and uploaded the artifacts to the apache 
> staging repo for you all to review.
> 
> I checked out the license, notice, and source code headers and everything 
> looked ok to me from that perspective.
> 
> In the future, we may want to release this in sync with the rest of the geode 
> artifacts, but for now I'm just trying to create an official release that 
> follows the release policy - 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.htmldata=04%7C01%7Cbakera%40vmware.com%7C6ff73330c3d04d781bab08d9c66843ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758973391327661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=cf0zjYb3hbL5%2B670qR3ZkqxNeNViyAoNl4TBQLJgYFg%3Dreserved=0.
> 
> -Dan
> 
> From: Dan Smith 
> Sent: Thursday, December 16, 2021 11:25 AM
> To: dev@geode.apache.org 
> Subject: [VOTE] - Apache Geode Kafka Connector 1.1.0
> 
> Hello Geode Dev Community,
> 
> This is a release candidate for Apache Geode Kafka Connector version 1.1.0. 
> This contains a bump to log4j 2.16.
> 
> Please do a review and give your feedback, including the checks you performed.
> 
> Voting deadline:
> 3PM PST Monday, December 20 2021.
> 
> Please note that we are voting upon the source tag: rel/v1.1.0
> 
> 
> Source and Binary Distributions: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2Fkafka-connector-1.1.0%2Fdata=04%7C01%7Cbakera%40vmware.com%7C6ff73330c3d04d781bab08d9c66843ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758973391327661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DBw2P1HChOyQ2kmPd6PWOxbN7jzqWB7i1Zy1nU3%2Bakg%3Dreserved=0
> 
> Github: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Ftree%2Frel%2Fv1.1.0data=04%7C01%7Cbakera%40vmware.com%7C6ff73330c3d04d781bab08d9c66843ca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758973391327661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Z4Db0HA8cGK3Rql5v9kFAliLLmPuGmovDv2JJrj9TjQ%3Dreserved=0
> 
> Command to build the connector:
> mvn package
> 
> 
> 

Re: [DISCUSS] proposal to pare down old-version testing

[Anthony Baker]

Interesting data point:  40% of maven central downloads last month were for 
version 1.4.0. Of course those numbers can be easily skewed by CI bots, but 
still!

@Owen, I think your suggestion nicely improves practicality while continuing to 
support strong compatibility. In many cases it’s quite a bit easier to upgrade 
the Geode server cluster compared to potentially many, many client 
applications.  Supporting older client versions gives users time to upgrade, 
quicker access to bug fixes, and helps avoids downtime.

+1

Anthony


> On Dec 22, 2021, at 7:13 PM, Owen Nichols  wrote:
> 
> Since adopting our N-2 support policy, the list of released versions in 
> /settings.gradle has ballooned to over 30 entries [1].
> 
> CI tests use this list to confirm that we don’t break rolling upgrade ability 
> or compatibility with older clients, but some of these tests don’t seem to 
> scale well: PR#7203 to add the most recent 3 releases (bringing the total to 
> 33) is unable to pass CI after 8 tries.
> 
> Possible solutions fall into two categories: keep the full list and throw 
> developers and/or more hardware at the struggling tests, or concede that 
> testing every version is not a scalable approach and find ways to shorten the 
> list, e.g. randomly select a subset of old versions at runtime, or manually 
> pare down the list.
> 
> I propose to shorten the list [2] by keeping only the latest patch for each 
> minor (unless the client or server protocol version has changed, so also keep 
> the patch prior to 1.12.1 and prior to 1.13.2).  As long as a patch release 
> doesn’t change the client or server protocol version, I see low value in 
> testing upgrades from every patch version to every future version forever.  
> The months between patch releases already provide plenty of upgrade coverage 
> on that specific patch, then we can move on to the next…even if there could 
> somehow be a corner-case where transitive property of upgradability doesn’t 
> hold, most users probably take the latest-to-latest upgrade path anyway, 
> which will always be tested.
> 
> Let’s keep discussion open until 3PM PST Jan 5.  In case of no response, I 
> will assume lazy consensus and update settings.gradle as proposed [2].
> 
> 
> 
> [1] Current list from 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fsettings.gradle%23L72-L101data=04%7C01%7Cbakera%40vmware.com%7C803bd50439204bf790a208d9c5c24361%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758261648196421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=X3SpCCjuvQo9JO01Di8HM29eKpXPzH9mr2vvpt2fSww%3Dreserved=0
>  :
> 1.0.0-incubating
> 1.1.0
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.0
> 1.9.1
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.1
> 1.12.2
> 1.12.3
> 1.12.4
> 1.12.5
> 1.12.6
> 1.12.7*
> 1.13.0
> 1.13.1
> 1.13.2
> 1.13.3
> 1.13.4
> 1.13.5
> 1.13.6*
> 1.14.0
> 1.14.1
> 1.14.2*
> *=released, but not yet added to settings.gradle due to PR#7203 not able to 
> pass CI due to size of version list
> 
> [2] Proposed shortlist:
> 1.1.1
> 1.2.0
> 1.3.0
> 1.4.0
> 1.5.0
> 1.6.0
> 1.7.0
> 1.8.0
> 1.9.2
> 1.10.0
> 1.11.0
> 1.12.0
> 1.12.7
> 1.13.1
> 1.13.6
> 1.14.2
> 

Re: [DISCUSS] Adding LTGM as gating PR checks

[Anthony Baker]

Thanks Robert, I think this is important. I think this is a good first step. 

In future I think we should consider adding a CI job to ensure that 
pre-existing security errors are addressed. Perhaps GitHub code scanning is 
worth investigating since they have acquired the LGTM product.

Anthony


> On Dec 16, 2021, at 10:08 AM, Robert Houghton  wrote:
> 
> We have had LGTM tests enabled on Apache Geode PRs for quite some time, and 
> have done a great job of trending those warnings and errors to in the right 
> direction. I would like to make the change to our GitHub to make those 
> changes blocking for all new PRs, given their reliability and 
> lack-of-flakiness.
> 
> Does anyone have strong feelings against that?
> 
> -Robert Houghton

Re: Question related to orphaned .drf files in disk-store

[Anthony Baker]

Got it, that seems entirely reasonable.

Anthony


> On Dec 3, 2021, at 7:37 AM, Jakov Varenina  wrote:
> 
> Hi Anthony,
> 
> Not sure normally, but at the moment when we were investigating the issue 
> there were 21 .crf files in disk-store (on one server) with default 
> max-oplog-size (1GB) and compaction-threshold (50%).
> 
> BRs/Jakov
> 
> On 02. 12. 2021. 17:06, Anthony Baker wrote:
>> Related but different question:  how many active oplogs do you normally see 
>> at one time?  You may want to adjust the max-oplog-size if the default of 1 
>> GB is too small.
>> 

Re: Question related to orphaned .drf files in disk-store

[Anthony Baker]

Related but different question:  how many active oplogs do you normally see at 
one time?  You may want to adjust the max-oplog-size if the default of 1 GB is 
too small.

On Dec 2, 2021, at 1:11 AM, Jakov Varenina 
mailto:jakov.varen...@est.tech>> wrote:

Hi Dan,

We forget to mention that we actually configure off-heap for the regions, so 
cache entry values are stored outside the heap memory. Only Oplog objects that 
are not compacted and that have .crf file are referencing the live entries from 
the cache. These Oplog objects are not stored in onlyDrfOplogs hashmap. In 
onlyDrfOplogs map are only Oplog objects that are representing orphaned .drf 
files (the one without accompanying .crf and .krf file). These objects have 
been compacted and doesn't contain a reference to any live entry from the 
cache. All of these 18G is actually occupied by empty pendingKrfTags hashmaps.

In this case there are 7680 Oplog objects stored in onlyDrfOplogs. Every Oplog 
object has it's own regionMap hashmap. Every regionMap can contain hundreds of 
empty pendingKrfTags hashMaps. When you bring all that together you get more 
then 18G of unnecessary heap memory.

Thank you all for quick review of PR and fast response to our questions!

BRs/Jakov


On 02. 12. 2021. 00:25, Dan Smith wrote:
Interesting. It does look like that pendingKrfTags structure is wasting memory.

I think that retained heap of 20 gigabytes might include your entire cache, 
because those objects have references back to the Cache object. However with 6K 
oplogs each having an empty map with 4K elements that does add up.

-Dan

*From:* Jakov Varenina mailto:jakov.varen...@est.tech>>
*Sent:* Tuesday, November 30, 2021 5:53 AM
*To:* dev@geode.apache.org 
mailto:dev@geode.apache.org>>
*Subject:* Re: Question related to orphaned .drf files in disk-store

Hi Dan and all,


Just to provide you the additional picture that better represents the severity 
of the problem with pendingKrfsTag. So when after you check the second picture 
in below mail, then please come back and check this one also. Here you can see 
that the pendingKerfTags is empty and has capacity of 9,192 allocated in memory.



Sorry for any inconvenience.

BRs/Jakov


On 30. 11. 2021. 09:32, Jakov Varenina wrote:

Hi Dan,


Thank you for your answer!


We have identify memory leak in Oplog objects that are representing orphaned 
.drf files in heap memory. In below screenshoot you can see that 7680 
onlyDrfOplogs consume more than 18 GB of heap which doesn't seem correct.



In below picture you can see that the drfOnlyPlog.Oplog.regionMap.pendingKrfTgs 
structure is responsible for more then 95% of drfOnlyOplogs heap memory.




The pendingKrfTags structure is actually empty (although it consumes memory 
because it was used previously and the size of the HashMap was not reduced) and 
not used by the onlyDrfOplogs objects. Additionally, the regionMap.liveEntries 
linked list has just one element (fake disk entry OlogDiskEntry indicating that 
it is empty) and it is also not used. You can find more details why 
pedingKrfTags sturcture remianed in memory for Oplog object representing 
orphaned .drf file and possible solution in the following ticket and the PR:


https://issues.apache.org/jira/browse/GEODE-9854 


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7145data=04%7C01%7Cbakera%40vmware.com%7Cbd2758bd10a54592fcef08d9b573cebe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740331264764503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ua49Y%2F4PwKhQHHgz898uxDLde%2BZpZZFxMBY%2FgIL8%2BEE%3Dreserved=0
 



BRs/Jakov



On 24. 11. 2021. 23:12, Dan Smith wrote:
The .drf file contains destroy records for entries in any older oplog. So even 
if the corresponding .crf file has been deleted, the .drf file with the same 
number still needs to be retained until the older .crf files are all deleted.

7680 does seem like a lot of oplogs. That data structure is just references to 
the files 

Re: Open socket handles build up over time (leaking?)

[Anthony Baker]

I’m curious - how do you assign a durable client id?  The id should be unique 
to a client and not shared among a pool of clients. 

Anthony


> On Nov 17, 2021, at 11:22 AM, Darrel Schneider  wrote:
> 
> I think you found the leak!
> My understanding of the code in registerClientInternal (I'm looking at the 
> current develop branch) is that when it logs the warning "Duplicate durable 
> clients are not allowed" that it considers the current client connect attempt 
> to have failed. It writes this response back to it: 
> REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT. This will cause the client to throw 
> ServerRefusedConnectionException. What seems wrong about this method is that 
> even though it sets "unsuccessfulMsg" and correctly sends back a handshake 
> saying the client is rejected, it does not throw an exception and it does not 
> close "socket". I think right before it calls performPostAuthorization it 
> should do the followiing:
> if (unsuccessfulMsg != null) {
>  try {
>socket.close();
>  } catch (IOException ignore) {
>  }
> } else {
>performPostAuthorization(...)
> }
> 
> From: Leon Finker 
> Sent: Wednesday, November 17, 2021 10:30 AM
> To: dev@geode.apache.org 
> Subject: Re: Open socket handles build up over time (leaking?)
> 
> Following Darrel's excellent advice :) I think I tracked down the area
> of the socket handle leak. As the article suggested, I ran the lsof
> capture every 5 minutes. I then traced back the cleaned up socket
> handles to the valid lsof entries. I verified a bunch of them and they
> all ended up pointing to the same durable connection cases that fail
> as follows:
> 
> [2021-11-17 14:05:13,081Z][info  17> tid=32115] :Cache server: Initializing secondary server-to-client
> communication socket: Socket[addr=/x.x.x.x,port=56090,localport=40011]
> [2021-11-17 14:05:13,083Z][warn  17> tid=32115] The requested durable client has the same identifier (
> tpdemo2@x_gem_x ) as an existing durable client (
> CacheClientProxy[identity(TS02493(tpdemo2@x:loner):60759:9243242e:tpdemo2@x(version:GEODE
> 1.14.0),connection=1,durableAttributes=DurableClientAttributes[id=tpdemo2@TS02493@21.5.3@8.2.6@2021.5.8_gem_Amoeba;
> timeout=86400]); port=53976; primary=true; version=GEODE 1.14.0] ).
> Duplicate durable clients are not allowed.
> [2021-11-17 14:05:13,084Z][warn  17> tid=32115] CacheClientNotifier: Unsuccessfully registered client
> with identifier
> identity(TS02493(tpdemo2@x:loner):60759:9243242e:tpdemo2@x(version:GEODE
> 1.14.0),connection=1,durableAttributes=DurableClientAttributes[id=tpdemo2@TS02493@21.5.3@8.2.6@2021.5.8_gem_Amoeba;
> timeout=86400]) and response code 64
> [2021-11-17 14:05:13,098Z][warn  34> tid=290] Server connection from
> [identity(TS02493(tpdemo2@x:loner):60759:9243242e:tpdemo2@x(version:GEODE
> 1.14.0),connection=1,durableAttributes=DurableClientAttributes[id=tpdemo2@TS02493@21.5.3@8.2.6@2021.5.8_gem_Amoeba;
> timeout=86400]); port=60242]: connection disconnect detected by EOF.
> 
> I then counted the number of those errors and found that the
> difference is exactly the same as the leaked socket handles. So
> everything points to this area in the server code. But I tried to
> reproduce this in debugger and stepped through the geode code without
> finding where the socket might be leaked. Put breakpoint on
> CacheClientNotifier.registerClientInternal and the line where that
> error happens. But then again the exception seems to bubble up to
> AcceptorImpl.run where the is catch for IOException. And in case of
> IOException, the client socket is closed. Is this the right socket I'm
> after?
> 
> Does this make it any clearer for someone who is more familiar with
> the code? NOTE: the duplicate durable client happens sometimes due to
> race conditions with reconnects (I think). It's not happening all the
> time. It's not causing any problems to the client in general. But the
> server leak eventually causes us to run out of file handles for the
> process :(
> 
> Thank you!
> 
> 
> On Tue, Nov 16, 2021 at 4:33 PM Leon Finker  wrote:
>> 
>> Hi Darrel,
>> 
>> Thank you! I'll try to track it!
>> 
>> On Tue, Nov 16, 2021 at 2:42 PM Darrel Schneider  wrote:
>>> 
>>> This link: 
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.mulesoft.com%2Fs%2Farticle%2FHow-to-identify-leaked-file-descriptors-that-are-shown-only-as-cant-identify-protocol-in-lsofdata=04%7C01%7Cbakera%40vmware.com%7C3b69c55afcfa4eabc50508d9a9ffa1a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637727737664517186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=EtGD5SQu2%2B7CYGpqvcY362u94VsWy9ZYyrg502325kw%3Dreserved=0
>>>  points out that once the fd gets into this "can't identify protocol" state 
>>> you can no longer figure out things like what port(s) and addresses are 
>>> associated with the fd. They suggest running lsof periodically to catch 
>>> that fd (in 

Re: Failed durable client connection initialization can sometimes leak client socket handle?

[Anthony Baker]

I just responded to your latest question, but if you have logs or a test case 
you could share that would be really helpful.

Thanks,
Anthony


> On Nov 10, 2021, at 10:01 AM, Leon Finker  wrote:
> 
> Hi,
> 
> In AcceptorImpl.run, the accepted client socket seems to only be
> closed when there is IOException. I can't prove it, but I think there
> can sometimes be non IO exception here as well and then the client
> socket will not be closed? Also, can we please add a catch for other
> kinds of exceptions and at least log them as errors?
> 
> The symptoms we have are like this:
> 1. Durable client has a connection problem during initialization.
> 2. Durable client ends up with orphaned durable HA region (the one
> prefixed with_gfe_durable_client_with_id_)
> 3. Now the client automatically reconnects and the geode server fails
> to properly initialize the client. Most likely because the region
> already has an error. If inspecting the regions at runtime, we indeed
> can see durable region for the client without CacheClientProxy
> properly created and added to the proxies collection.
> 4. We observe a pretty rapid (over few days) memory leak and socket handles 
> leak
> 5. This leak stops as soon as we destroy that internal durable region
> (partially through reflection) for the client and client can then
> properly reconnect and initialize its region and proxy.
> 
> Does this ring any bells for anyone?
> 
> Thank you

Re: Open socket handles build up over time (leaking?)

[Anthony Baker]

Hi, thanks for this report.  Some questions to help us help you—

- What OS for client and server?
- Are you seeing the sockets clean up over time or do they persist until a 
reboot?
- Does netstat give you any additional information about the sockets?  Are any 
in TIME_WAIT status?
- Do you have a tcpdump of the socket? 
- What is the scenario?  Is it “normal” operation or is the client or server 
killed?
- Do you have a reproducible test case?

Thanks,
Anthony




> On Nov 16, 2021, at 9:28 AM, Leon Finker  wrote:
> 
> Hi,
> 
> We observe in our geode (1.14 - same before as well in 1.13) cache
> server (that supports durable client sessions) an increase in half
> opened sockets. It seems there is a socket leak. Could someone
> recommend how to track the leak down? It's not obvious where it's
> leaking...I can only suspect AcceptorImpl.run and where it only
> handles IOException. but I wasn't able to reproduce it in debugger
> yet...
> 
> lsof -p 344|grep "can't"
> 
> java 344   user  133u  sock0,6   0t0 115956017
> can't identify protocol
> java 344   user  142u  sock0,6   0t0 113361870
> can't identify protocol
> java 344   user  143u  sock0,6   0t0 111979650
> can't identify protocol
> java 344   user  156u  sock0,6   0t0 117202529
> can't identify protocol
> java 344   user  178u  sock0,6   0t0 113357568
> can't identify protocol
> ...
> 
> lsof -p 344|grep "can't"|wc -l
> 934
> 
> Thank you

Re: October Community Meeting

[Anthony Baker]

Looking forward to it!  There has been some good discussion on query resource 
management [1] as well, perhaps we can pick up that topic another time if there 
sufficient interest.

Anthony

[1] 
https://cwiki.apache.org/confluence/display/GEODE/Throttling+of+OQL+queries?focusedCommentId=18874#comment-18874


On Sep 29, 2021, at 9:09 AM, Alexander Murmann 
mailto:amurm...@vmware.com>> wrote:

Hi everyone!

Next Thursday October 6th is our next Community Meeting. Jacob Barrett has 
started some discussions on the mailing list about modularization. This is a 
great topic for our upcoming meeting. Jake won't be able to join till one hour 
after our regular time. I hope everyone is fine if we have the October meeting 
an hour later at 9:00 Pacific (16:00 UTC).

Find the meeting 
details
 on the wiki.

Looking forward to seeing you all next week!

Re: Requesting eligibility for JIRA ticket assignment

[Anthony Baker]

Welcome Kaustubh!  Please don’t hesitate to shout out if you have questions or 
need help.

Anthony


> On Sep 23, 2021, at 2:17 PM, Mark Bretl  wrote:
> 
> Hi Kaustubh,
> 
> I have updated your permissions on the GEODE project, you now should be
> able to edit and assign issues.
> 
> Please let me know if you have any questions,
> 
> Mark
> 
> On Thu, Sep 23, 2021 at 10:12 AM Dave Barnes  wrote:
> 
>> +1
>> Kaustubh's contribution was a good one.
>> 
>> On Thu, Sep 23, 2021 at 8:26 AM Kaustubh Maske Patil 
>> wrote:
>> 
>>> Hi,
>>> I recently made my first contribution to apache/geode on ticket
>> GEODE-9619
>>> and would like to request eligibility for assignment to that ticket, and
>>> hopefully more in the future :)
>>> 
>>> This is my GitHub profile 
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnikochikodata=04%7C01%7Cbakera%40vmware.com%7C3d50caebf50b458fe4f908d97ed7a134%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637680286857857922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=r5pDmyiy4wQOx7o0NpTJ7ksRLTMkETUIO1LsTVuE9zA%3Dreserved=0
>>> 
>>> Thanks!
>>> 
>>> Best,
>>> Kaustubh Maske Patil
>>> 
>> 

Re: [DISCUSS] Modularizing new WAN TX Batching (and Modularization Efforts in General)

[Anthony Baker]

I know we have folks spread across different time zones, would a 9AM PST / 4PM 
UTC discussion work?  Yes, we will post the recording afterwards but that makes 
it hard to ask live questions :-)

Anthony


> On Sep 21, 2021, at 12:14 AM, Alberto Gomez  wrote:
> 
> I think this is a great initiative. Not only are you giving a reminder about 
> the need to implement new features in a modular and pluggable way, but you 
> are also providing a real example with an already implemented not in the best 
> way feature, to show the steps to follow in the right direction for this and 
> future features.
> 
> I would be interested in attending to a live walkthrough over the details of 
> the changes.
> 
> Thanks,
> 
> Alberto
> 
> From: Jacob Barrett 
> Sent: Tuesday, September 21, 2021 3:04 AM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] Modularizing new WAN TX Batching (and Modularization 
> Efforts in General)
> 
> Unfortunately I can’t do meetings that early. The earliest I could do that 
> day is 9am PDT.
> 
>> On Sep 20, 2021, at 3:34 PM, Anthony Baker  wrote:
>> 
>> The approach makes sense to me. The idea of a stable core + extensibility 
>> is a common and successful pattern in many OSS projects.
>> 
>> @Jake, you want to discuss at the next Geode Community meeting in Oct?
>> 
>> Anthony
>> 
>> 
>>> On Sep 20, 2021, at 1:48 PM, Jacob Barrett  wrote:
>>> 
>>> Devs,
>>> 
>>> We need to be doing a better job with implementing new features in a 
>>> modular and plugable way. We have had discussions in the past but we 
>>> haven’t been the best at sticking to it. Most recently we began work on a 
>>> modified version of WAN that supports transactional batching. Rather than 
>>> implement it in a plugable model we modified the existing implementation 
>>> with a new property that changes the internal behavior of the 
>>> implementation. This is a clear smell that what we have should be plugable 
>>> and modularized. I am not suggesting that we run out and define clear 
>>> public SPIs for everything or come up with some complicated plan to 
>>> re-architect everything into modules but rather that we take small steps. I 
>>> will argue that when we are adding functionality to a core service that is 
>>> the point we should consider steps to break it up into clear module 
>>> components. Think to yourself, what would it take for me to implement this 
>>> new functionality as its own module, meaning its own jar and Gradle 
>>> sub-project. As you begin to develop the solution you may find you need 
>>> some clean interfaces for it to extend from the core, that might be the 
>>> start of an internal SPI. You may find that some concrete classes you would 
>>> have normally modified just need to be extended with a few protected 
>>> methods to implement alternative logic.
>>> 
>>> I think we should focus efforts on extracting an interface to plug in 
>>> different WAN gateway implementations so that existing implementations 
>>> aren’t modified with new behavior. With proper interface extraction we can 
>>> more easily unit test around WAN gateways. By keeping implementations small 
>>> we can more easily test them in isolation. Making them all plugable allows 
>>> distributions of Geode to deliver specific implementations they would like 
>>> to support without impacting the existing implementations. It also frees 
>>> Geode to release new experimental or beta implementations of WAN gateways 
>>> without impacting the existing implementations rather than delaying 
>>> releases waiting for modified WAN gateways to be production ready and fully 
>>> tested.
>>> 
>>> In looking at the geode-wan module one might notice that it was already 
>>> designed to be plugable. Unfortunately it isn’t that easy. This SPI was 
>>> originally there to provide a way for Geode to be donated initially without 
>>> WAN support. It turns out that most of the core to WAN is actually still in 
>>> geode-core and only some of the “secret sauce” was moved into geode-wan. 
>>> The bulk of the geode-core code for WAN is actually in support of the 
>>> region queues for WAN and AEQ, so moving it into geod-wan would have cut 
>>> off AEQ. While it would be possible to utilize this SPI for providing 
>>> alternative gateway implementations it is very high level,so much of the 
>>> alternative implementations would be duplications, and it doesn’t allow for 
>>> 

Re: [DISCUSS] Modularizing new WAN TX Batching (and Modularization Efforts in General)

[Anthony Baker]

The approach makes sense to me. The idea of a stable core + extensibility is a 
common and successful pattern in many OSS projects.  

@Jake, you want to discuss at the next Geode Community meeting in Oct?

Anthony


> On Sep 20, 2021, at 1:48 PM, Jacob Barrett  wrote:
> 
> Devs,
> 
> We need to be doing a better job with implementing new features in a modular 
> and plugable way. We have had discussions in the past but we haven’t been the 
> best at sticking to it. Most recently we began work on a modified version of 
> WAN that supports transactional batching. Rather than implement it in a 
> plugable model we modified the existing implementation with a new property 
> that changes the internal behavior of the implementation. This is a clear 
> smell that what we have should be plugable and modularized. I am not 
> suggesting that we run out and define clear public SPIs for everything or 
> come up with some complicated plan to re-architect everything into modules 
> but rather that we take small steps. I will argue that when we are adding 
> functionality to a core service that is the point we should consider steps to 
> break it up into clear module components. Think to yourself, what would it 
> take for me to implement this new functionality as its own module, meaning 
> its own jar and Gradle sub-project. As you begin to develop the solution you 
> may find you need some clean interfaces for it to extend from the core, that 
> might be the start of an internal SPI. You may find that some concrete 
> classes you would have normally modified just need to be extended with a few 
> protected methods to implement alternative logic.
> 
> I think we should focus efforts on extracting an interface to plug in 
> different WAN gateway implementations so that existing implementations aren’t 
> modified with new behavior. With proper interface extraction we can more 
> easily unit test around WAN gateways. By keeping implementations small we can 
> more easily test them in isolation. Making them all plugable allows 
> distributions of Geode to deliver specific implementations they would like to 
> support without impacting the existing implementations. It also frees Geode 
> to release new experimental or beta implementations of WAN gateways without 
> impacting the existing implementations rather than delaying releases waiting 
> for modified WAN gateways to be production ready and fully tested. 
> 
> In looking at the geode-wan module one might notice that it was already 
> designed to be plugable. Unfortunately it isn’t that easy. This SPI was 
> originally there to provide a way for Geode to be donated initially without 
> WAN support. It turns out that most of the core to WAN is actually still in 
> geode-core and only some of the “secret sauce” was moved into geode-wan. The 
> bulk of the geode-core code for WAN is actually in support of the region 
> queues for WAN and AEQ, so moving it into geod-wan would have cut off AEQ. 
> While it would be possible to utilize this SPI for providing alternative 
> gateway implementations it is very high level,so much of the alternative 
> implementations would be duplications, and it doesn’t allow for both 
> implementations to sit side by side at runtime. I would actually suggest we 
> eliminate this public SPI in favor of just the geode-wan core module that it 
> is and eventually migrate the region queue code into its own module as well, 
> but these are for another day.
> 
> Looking closer at the WAN gateways themselves there is mostly a pluggable 
> interface already there with the existing interfaces. I spent a little time 
> pulling apart an internal SPI and it was quite easy. With a small 
> modification to gfsh and cache xml to specify that alternative implementation 
> by name is all that needs to be done immediately to configure an alternative. 
> Without extracting too many of the common implementation out into its own 
> module just a few of the classes in geode-core can be modified to provide 
> empty implementation of key overridable plug-in points for the TX batching 
> implementation. The result is that the TX batching module can be added to the 
> classpath and be configured as a gateway sender without injecting any of the 
> TX batching specific code into geode-core or geode-wan. Deeper details can be 
> found at the end of this discussion.
> 
> This solution isn’t perfect but it is a step in the right direction. The more 
> we continue to extract and extend the closer we will get to a true pluggable 
> architecture. The key to being successful will be to keep the changes to the 
> core components small and the interfaces between modules internal. If we all 
> make an effort towards this, both in our code and in our reviews of others 
> code, we can keep the efforts small and manageable.
> 
> I would love feedback and thoughts on this suggestion.
> 
> -Jake
> 

ApacheCon: OLTP Application Data Services with Apache Geode

[Anthony Baker]

Don’t miss this great talk [1] by Gregory Green on Microservices with Apache 
Geode!  Happens tomorrow at 7:10am PST / 14:10 UTC.

From the abstract:

Real-time transactions can be fast and furious. Think about building the next 
big retail market app. Users of the app need to get the answers as quickly as 
possible. Any slow down to response times will have those users going somewhere 
else. When the application is popular more and more users will come. Having 
highly scalable and fast data services is essential.
This session will highlight and describe

• What is OLTP?
• What are its characteristics?
• What are the data service challenges?

How Apache Geode can be used to meet needs such as
• Performance
• Scalability
• Strong Consistency
• NoSQL characteristics
• High Availability
• Fault Tolerance
• WAN Replication

Anthony

[1] https://www.apachecon.com/acah2021/tracks/apimicro.html

Re: Reminder: Geode community meeting

[Anthony Baker]

Thanks to Patrick for a great presentation on how this new feature will make it 
easier to manage dependencies in server side code.  The wiki page has a link to 
the recording if you missed it.

Anthony


> On Sep 8, 2021, at 1:07 PM, Anthony Baker  wrote:
> 
> Hi all,
> 
> Reminder that tomorrow is a Geode community meeting.  Patrick Johnson will be 
> discussing his work on class loader isolation for user code.  Join us at 
> 8:00am Pacific (15:00 UTC)!  
> 
> Details here:
> https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes
> 
> See you there!
> Anthony
> 

Reminder: Geode community meeting

[Anthony Baker]

Hi all,

Reminder that tomorrow is a Geode community meeting.  Patrick Johnson will be 
discussing his work on class loader isolation for user code.  Join us at 8:00am 
Pacific (15:00 UTC)!  

Details here:
https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes

See you there!
Anthony

Re: Odg: NullPointerException while create region during server restart

[Anthony Baker]

One thing you might check is why the create region request from gfsh was 
allowed to proceed before initialization was complete.  That is, cluster config 
and all associated configuration like the pdx registry should be created before 
any *new configuration* requests are processed.

I’m not sure what the code path looks like but that might be a place to start 
investigating.

Anthony


> On Jul 8, 2021, at 4:27 AM, Mario Kevo  wrote:
> 
> Hi Anthony,
> 
> It happened while the server is starting and creating a cache (while fills in 
> the content of a cache based on the creation object's state). The NPE occurs 
> when the "create region" command is executed before pdxRegistry is 
> initialized. There is that part of the code where pdxRegistry is initialized: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNordix%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2Fcache%2Fxmlcache%2FCacheCreation.java%23L529data=04%7C01%7Cbakera%40vmware.com%7C45e30baf46fc4661ec3d08d942036bd5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637613404734267138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=viKM8UDdp5xydX0AcB03xte%2Bxsdv%2F0p68qXjyca1HW4%3Dreserved=0
> 
> Before this part of the code is executed it has that pdxRegistry is null, and 
> it throws the NPE in findDiskStore.
> 
> 
> BR,
> Mario
> 
> Šalje: Anthony Baker 
> Poslano: 7. srpnja 2021. 17:58
> Prima: dev@geode.apache.org 
> Predmet: Re: NullPointerException while create region during server restart
> 
> When the NPE occurs, has the server completed its bootstrapping from cluster 
> configuration yet?
> 
> Anthony
> 
> 
>> On Jul 6, 2021, at 12:06 AM, Mario Kevo  wrote:
>> 
>> Hi Geode devs,
>> 
>> I opened a new ticket https://issues.apache.org/jira/browse/GEODE-9409 
>> regarding NullPointerException on creating region while one of the servers 
>> is restarting.
>> If we run the "create region" command through gfsh while the server is 
>> starting it passed, but if the server is restarted then it fails. The 
>> difference is that when we restarted the server, we kill them and start 
>> again. As it has already a server directory, it takes more time to get the 
>> server up as expected.
>> In that case, if we run the "create region" command it can happen that the 
>> cache is not fully created and we are trying to do something on that. That 
>> can lead to the NullPointerException, as creating region catches pdxRegistry 
>> from the cache while doing findDiskStore, but sometimes it is not 
>> initialized in the cache yet. So every method run against that will throw 
>> NullPoniterException.
>> There is a part of the code where the exception is thrown:
>> 
>> DiskStoreImpl findDiskStore(RegionAttributes regionAttributes,
>>   InternalRegionArguments internalRegionArgs) {
>> // validate that persistent type registry is persistent
>> if (getAttributes().getDataPolicy().withPersistence()) {
>>   getCache().getPdxRegistry().creatingPersistentRegion();
>> }
>> 
>> As I already mention, getPdxRegistry(LocalRegion.java) will be null if it is 
>> not yet initialized in create(CacheCreation.java):
>> 
>> DiskStoreAttributesCreation pdxRegDSC = initializePdxDiskStore(cache);
>> 
>> cache.initializePdxRegistry();
>> 
>> createDiskStores(cache, pdxRegDSC);
>> 
>> I tried to do some fixes, but without a success. 
>> It can be passed if we add some retry and sleep, but that is not acceptable.
>> 
>> So if someone has some idea how to do some wait until pdxRegistry is 
>> initialized or something else what will help us to avoid this problem?
>> 
>> BR,
>> Mario
> 

Re: NullPointerException while create region during server restart

[Anthony Baker]

When the NPE occurs, has the server completed its bootstrapping from cluster 
configuration yet?

Anthony


> On Jul 6, 2021, at 12:06 AM, Mario Kevo  wrote:
> 
> Hi Geode devs,
> 
> I opened a new ticket https://issues.apache.org/jira/browse/GEODE-9409 
> regarding NullPointerException on creating region while one of the servers is 
> restarting.
> If we run the "create region" command through gfsh while the server is 
> starting it passed, but if the server is restarted then it fails. The 
> difference is that when we restarted the server, we kill them and start 
> again. As it has already a server directory, it takes more time to get the 
> server up as expected.
> In that case, if we run the "create region" command it can happen that the 
> cache is not fully created and we are trying to do something on that. That 
> can lead to the NullPointerException, as creating region catches pdxRegistry 
> from the cache while doing findDiskStore, but sometimes it is not initialized 
> in the cache yet. So every method run against that will throw 
> NullPoniterException.
> There is a part of the code where the exception is thrown:
> 
> DiskStoreImpl findDiskStore(RegionAttributes regionAttributes,
>InternalRegionArguments internalRegionArgs) {
>  // validate that persistent type registry is persistent
>  if (getAttributes().getDataPolicy().withPersistence()) {
>getCache().getPdxRegistry().creatingPersistentRegion();
>  }
> 
> As I already mention, getPdxRegistry(LocalRegion.java) will be null if it is 
> not yet initialized in create(CacheCreation.java):
> 
> DiskStoreAttributesCreation pdxRegDSC = initializePdxDiskStore(cache);
> 
> cache.initializePdxRegistry();
> 
> createDiskStores(cache, pdxRegDSC);
> 
> I tried to do some fixes, but without a success. 
> It can be passed if we add some retry and sleep, but that is not acceptable.
> 
> So if someone has some idea how to do some wait until pdxRegistry is 
> initialized or something else what will help us to avoid this problem?
> 
> BR,
> Mario

Re: CFP for ApacheCon 2021 closes in ONE WEEK

[Anthony Baker]

Hi Greg, great news!  Forwarding your acceptance over to Rich and the ApacheCon 
planning team.  Thanks!

Anthony


> On Jun 28, 2021, at 11:19 AM, Gregory Green  wrote:
> 
> Hello team,
> 
> I do not see where I can accept the invite in the following link/info?
> 
> Dear Gregory Green,
> 
> Congratulations! We are pleased to tell you that your talk, "OLTP Application 
> Data Services with Apache Geode”
> has been accepted for ApacheCon 2021. (If you submitted additional proposals, 
> you
> will receive separate notifications regarding each proposal.)
> 
> Please confirm that you will be attending by responding to this email. You 
> will also need to register for the event, at 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fregister.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0BdAHjnh2hqid63H8a9bTE%2F8HjG11XUB0GvTpeehR5U%3Dreserved=0,
>  in order to be able to give your presentation. Please do not put this off, 
> as that will make the scheduling process more difficult - please go do that 
> now. Thanks.
> 
> With regards,
> The team behind ApacheCon 2021
> 
> 
> 
> -
> Gregory Green | Advisor Solution Engineer | Tanzu Data 
> Mobile: 732.737.7119| Email: grego...@vmware.com 
> --
> Articles/Videos
> Monoliths to Microservices? Don’t Forget to Transform the Data Layer 
> 
> A Caching Approach to Data Transformation of Legacy RDBMS 
> 
> How to Build Modern Data Pipelines with GemFire and SCDF 
> 
> GemFire AWS Quickstart 
> 
> 
> 
> 
> On 4/23/21, 11:03 AM, "Rich Bowen"  wrote:
> 
>[You are receiving this because you're subscribed to one or more dev@
>mailing lists for an Apache project, or the ApacheCon Announce list.]
> 
>Time is running out to submit your talk for ApacheCon 2021.
> 
>The Call for Presentations for ApacheCon @Home 2021, focused on Europe
>and North America time zones, closes May 3rd, and is at
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apachecon.com%2Facah2021%2Fcfp.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DciPvLuH%2BJGlMqt9P85EKwL5B9fHF2PVeQ9PtXSGrLg%3Dreserved=0
> 
>The CFP for ApacheCon Asia, focused on Asia/Pacific time zones, is at
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Facasia2021%2Fcfp.htmldata=04%7C01%7Cbakera%40vmware.com%7C3035655129e94260176508d93a633c54%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605020159625250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YiYaphF%2FVjBBSvDf4BLqydA%2BGzx1Gs2rWffWZaANCvo%3Dreserved=0
>  and also closes on May 3rd.
> 
>ApacheCon is our main event, featuring content from any and all of our
>projects, and is your best opportunity to get your project in front of
>the largest audience of 

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

[Anthony Baker]

If we have consensus, no need to VOTE.

> On Jun 9, 2021, at 12:52 PM, Owen Nichols  wrote:
> 
> Ok, I'm on board with changing stress-new-test from a required PR check to 
> non-required.  It's simple, codeowners still have the final say, and it 
> neatly avoids the whole topic of overrides.  Time to take a [VOTE]?
> 

Fwd: [NOTICE] Git web site publishing to be done via .asf.yaml only as of July 1st

[Anthony Baker]

I believe we will need to update the geode-site repo.


Begin forwarded message:

From: Daniel Gruno 
Date: May 31, 2021 at 7:41:05 AM MDT
To: Users 
Subject: [NOTICE] Git web site publishing to be done via .asf.yaml only as of 
July 1st
Reply-To: priv...@geode.apache.org

TL;DR: if your project web site is kept in subversion, disregard this email 
please. If your project web site is using git, and you have not deployed it via 
.asf.yaml, you MUST switch before July 1st or risk your web site goes stale.



Dear Apache projects,
In order to simplify our web site publishing services and improve self-serve 
for projects and stability of deployments, we will be turning off the old 
'gitwcsub' method of publishing git web sites. As of this moment, this involves 
120 web sites. All web sites should switch to our self-serve method of 
publishing via the .asf.yaml meta-file. We aim to turn off gitwcsub around July 
1st.


## How to publish via .asf.yaml:
Publishing via .asf.yaml is described at: https://s.apache.org/asfyamlpublishing
You can also see an example .asf.yaml with publishing and staging profiles for 
our own infra web site at: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Finfrastructure-website%2Fblob%2Fasf-site%2F.asf.yamldata=04%7C01%7Cbakera%40vmware.com%7C3c9e5ce4e2b04461fb5a08d92439bc68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637580652653660482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8rmWnJv6TUUJ1CnHboqk5bOhb0YrObQN3Kfq3JESq34%3Dreserved=0

In short, one puts a file called .asf.yaml into the branch that needs to be 
published as the project's web site, with the following two-line content, in 
this case assuming the published branch is 'asf-site':

publish:
 whoami: asf-site


It is important to note that the .asf.yaml file MUST be present at the root of 
the file system in the branch you wish to publish. The 'whoami' parameter acts 
as a guard, ensure that only the intended branch is used for publishing.


## Is my project affected by this?
The quickest way to check if you need to switch to a .asf.yaml approach is to 
check out site source page at https://infra-reports.apache.org/site-source/ - 
if your site is listed in yellow, you will need to switch. This page will also 
tell you which branch you are currently publishing as your web site. This is 
(should be) the branch that you must add a .asf.yaml meta file to.

The web site source list updates every hour. If your project site appears in 
green, you are already using .asf.yaml for publishing and do not need to make 
any changes.


## What happens if we miss the deadline?
If you miss the deadline, don't fret. Your site will of course still remain 
online as is, but new updates will not appear till you create/edit the 
.asf.yaml and set up publishing.


## Who do we contact if we have questions?
Please contact us at us...@infra.apache.org if you have any additional 
questions.


With regards,
Daniel on behalf of ASF Infra.

New PMC Chair [ was ASF Board Meeting Summary - May 19, 2021]

[Anthony Baker]

Hi everyone, please congratulate Dan Smith as the new PMC Chair [1] of Geode! 

Karen, thanks for your service!

Anthony

[1] https://www.apache.org/dev/pmc.html#chair 




> Begin forwarded message:
> 
> From: Sander Striker 
> Subject: ASF Board Meeting Summary - May 19, 2021
> Date: May 19, 2021 at 3:25:32 PM PDT
> To: committ...@apache.org
> Reply-To: bo...@apache.org
> 
> The May board meeting took place on the 19th.
> 
> The following directors were present:
> 
>  Bertrand Delacretaz, Roy T. Fielding, Sharan Foga, Justin Mclean, Craig L 
> Russell, Roman Shaposhnik, Sander Striker, Sheng Wu
> 
> The following officers were present:
> 
>  David Nalley, Matt Sicker, Ruth Suehle
> 
> The following guests were present:
> 
>  Balázs Donát Bessenyei, Dave Fisher, Daniel Gruno, Sally Khudairi, Gavin 
> McDonald, Daniel Ruggeri, Greg Stein
> 
> The April minutes were approved.
> Minutes will be posted to http://www.apache.org/foundation/records/minutes/
> 
> The following reports were not received and are expected next month:
> 
>  Report from the Apache BookKeeper Project [Sijie Guo]
>  Report from the Apache RocketMQ Project [Xiaorui Wang]
> 
> All of the received reports to the board were approved.
> 
> The following resolutions were passed unanimously:
> 
>  Change the Apache Parquet Project Chair (Xinli Shang, VP)
>  Change the Apache Geode Project Chair (Dan Smith, VP)
>  Change the Apache DataFu Project Chair (Eyal Allweil, VP)
> 
> The next board meeting will be on the 16th of June.

Re: Reminder to use draft mode

[Anthony Baker]

Side note:  I think using discussion to achieve consensus on topics like this 
tends to work better than [VOTE] threads.  If we fail to reach a consensus we 
can resort to a vote thread, or for reasons spelled out in [1].

IMHO,
Anthony

[1] https://www.apache.org/foundation/voting.html


On May 6, 2021, at 1:18 PM, Alberto Bustamante Reyes 
mailto:alberto.bustamante.re...@est.tech>> 
wrote:

 (Im wondering if a new VOTE thread is needed to approve it)

Re: JDK 16 Support?

[Anthony Baker]

Thanks for reporting this John.  The next LTS version of Java (17) is due later 
this year.  I think Geode needs to at least support every LTS version of Java 
and clearly we would need to fix errors like this. Do you see a need to support 
Java 16 now?

Anthony


On May 5, 2021, at 7:57 AM, John Blum 
mailto:jb...@vmware.com>> wrote:

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
-  at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
-  at 
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
-  at 
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
-  at 
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
-  at 
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
-  at 
org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
-  at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
-  at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
-  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
-  at 
org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
-  at 
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
-  at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: 
module java.base does not "opens java.nio" to unnamed module @40f9161a
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
-  at 
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
-  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
-  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
-  ... 22 common frames omitted
- 2021-04-30 14:57:13,638  INFO ributed.internal.membership.gms.Services: 606 - 
received leave request from 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001 
for 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
- 2021-04-30 14:57:13,640  INFO ributed.internal.membership.gms.Services: 617 - 
JoinLeave.processMessage(LeaveRequestMessage) invoked.  isCoordinator=true; 
isStopping=false; cancelInProgress=false
- 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler:  92 - 
Uncaught exception in thread Thread[P2P message reader for 
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001 
shared unordered uid=1 local port=53039 remote port=64063,10,main]
- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte 
buffer
-  at 
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
-  at 
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
-  at 
org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:217)
-  at 
org.apache.geode.internal.tcp.Connection.releaseInputBuffer(Connection.java:1512)
-  at org.apache.geode.internal.tcp.Connection.run(Connection.java:1495)
-  at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 

Re: Region data corruption due to missing PdxTypes

[Anthony Baker]

Retaining local pox types in the client after a disconnect will cause problems 
as you observed.  Take a look at the “ON_DISCONNECT_CLEAR_PDXTYPEIDS” property 
to improve this.

Anthony


> On May 4, 2021, at 4:36 AM, Mario Salazar de Torres 
>  wrote:
> 
> Hi everyone,
> 
> While debugging some coredumps in the native client related to 
> PdxTypeRegistry cleanup, I tried to reproduce the scenario with the Java 
> client API to see how it was handled.
> Thing is I've noticed that this scenario in the Java client might lead to 
> Geode storing a corrupted entry, meaning that queries won't work on those 
> regions containing corrupted entries.
> And with corrupted entries, I refer to entries using a missing PdxType. The 
> scenario involves a cluster restart. It's described below:
> 
>  1.  Start a cluster with 1 locator and 3 servers, and persistence is 
> disabled for PdxTypes.
>  2.  Setup a region called "test-region" with persistence disabled. It 
> doesn't mind whether is replicated or partitioned.
>  3.  In the client, instantiate the client region with PROXY region shortcut 
> and establish the connection toward the cluster.
>  4.  In the client, create a PdxInstance and put in into the "test-region" 
> with key "test".
>  5.  In the client, get the entry which key is "test", which turns out to be 
> the PdxInstance inserted in step 4.
>  6.  At this point, cluster is restarted, meaning that all the data is lost, 
> included PdxTypes.
>  7.  In the client, the PdxInstance obtained in step 5 is put into 
> "test-region" with key "test2"
>  8.  In the client, the following query is executed: "SELECT * FROM 
> /test-region WHERE value = -1".
> Such query fails with the message "Unknown pdx type=" and it 
> won't work until the corrupted entry is removed.
> 
> Also, the above scenario could be solved by enabling persistence for 
> PdxTypes, but if you have an unrecoverable issue in your cluster and you need 
> to spin up a backup,
> it could happen that PdxInstance's PdxType obtained step 5 is not present in 
> the backup, leading to the entry being inserted but, yet again, the PdxType 
> being missing.
> 
> It's worth mentioning that in the native client, this scenario currently 
> results in a coredump, but no data corruption,
> given that after losing the connection towards the cluster PdxTypeRegistry is 
> cleaned up and PdxTypes are obtained with its ID, rather than directly using 
> the object.
> 
> My question here are:
> 
>  *   Have you seen this issue before?
>  *   Is there a way to verify that PdxTypes are present in the cluster before 
> writing an entry which holds some PdxInstances?
> 
> Thanks,
> Mario.

Re: Odg: Geode retry/acknowledge improvement

[Anthony Baker]

Can you explain the scenario further?  Does the sidecar proxy both the sending 
and receiving socket (geode creates 2 sockets for each p2p member)?  In normal 
cases, closing these sockets should clear up any unacknowledged messages, 
freeing up the thread.

Anthony


> On Apr 20, 2021, at 7:31 AM, Mario Ivanac  wrote:
> 
> Hi,
> 
> after analysis, we  assume that proxy at reception of packets,  sends ACK on 
> TCP level, and after that moment proxy is restarted.
> This is the reason, we dont see tcp retries.
> 
> Simular problem to this (but not packet loss), can be reproduce on geode,
> if on existing connection, after request is sent, tcp reset is received. In 
> that case, at reception of reset
> connection will be closed, and thread will get stuck while waiting on reply.
> I will add reproduction steps in ticket.
> 
> ____
> Šalje: Anthony Baker 
> Poslano: 19. travnja 2021. 22:54
> Prima: dev@geode.apache.org 
> Predmet: Re: Geode retry/acknowledge improvement
> 
> Do you have a tcpdump that demonstrates the packet loss? How long did you 
> wait for TCP to retry the failed packet delivery (sometimes this can be 
> tweaked with tcp_retries2).  Does this manifest as a failed socket connection 
> in geode?  That ought to trigger some error handling IIRC.
> 
> Anthony
> 
> 
>> On Apr 19, 2021, at 7:16 AM, Mario Ivanac  wrote:
>> 
>> Hi all,
>> 
>> we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
>> are injected between cluster members.
>> While running traffic, if any Istio/SideCar is restarted, thread will get 
>> stuck indefinitely, while waiting for reply on sent message.
>> It seams that due to restarting of proxy, in some cases, messages are lost, 
>> and sending side is waiting indefinitely for reply.
>> 
>> https://issues.apache.org/jira/browse/GEODE-9075
>> 
>> My question is, what is your estimation, how much effort/work is needed to 
>> implement message retry/acknowledge logic in geode,
>> to solve this problem?
>> 
>> BR,
>> Mario
> 

Re: Geode retry/acknowledge improvement

[Anthony Baker]

Do you have a tcpdump that demonstrates the packet loss? How long did you wait 
for TCP to retry the failed packet delivery (sometimes this can be tweaked with 
tcp_retries2).  Does this manifest as a failed socket connection in geode?  
That ought to trigger some error handling IIRC.

Anthony


> On Apr 19, 2021, at 7:16 AM, Mario Ivanac  wrote:
> 
> Hi all,
> 
> we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
> are injected between cluster members.
> While running traffic, if any Istio/SideCar is restarted, thread will get 
> stuck indefinitely, while waiting for reply on sent message.
> It seams that due to restarting of proxy, in some cases, messages are lost, 
> and sending side is waiting indefinitely for reply.
> 
> https://issues.apache.org/jira/browse/GEODE-9075
> 
> My question is, what is your estimation, how much effort/work is needed to 
> implement message retry/acknowledge logic in geode,
> to solve this problem?
> 
> BR,
> Mario

Re: [DISCUSS and NOMINATE] Time for a new Geode PMC Chair

[Anthony Baker]

Karen, thanks for taking on the role of PMC Chair for Geode over the last few 
years!

The process for changing the Chair is outlined at [1].  The nominations and 
voting usually seem to occur on the PMC email list.  I’ll start a thread on 
private@.

Thanks,
Anthony

[1] https://www.apache.org/dev/pmc.html



> On Apr 7, 2021, at 1:58 PM, Karen Miller  wrote:
> 
> I've been the Geode PMC chair since December 2018. I'd like to step
> down from this position as soon as we nominate and then vote on a new
> PMC chair. (See https://www.apache.org/dev/pmc.html#newchair)
> 
> Please use this email thread to discuss and nominate. I believe the
> only requirement for the PMC chair is that the person already be a
> Geode PMC member. You are welcome to self-nominate, or to nominate
> another person. After nominations have been made, there will be a
> separate thread to allow current PMC members to vote on who will
> become the new PMC chair.
> 
> Thanks.
> Karen Miller
> I work for VMware.
> This email is written in my capacity as Chair of the Apache Geode PMC.

Re: [DISCUSS] CODEOWNERS mechanism feedback

[Anthony Baker]

I think for an active, healthy project community we need to balance two things 
that are somewhat oppositional:  make it easy to contribute and ensure the 
project meets the needs of our users for stability and robust behaviors in the 
face of failures.

> On Mar 17, 2021, at 9:45 AM, Jacob Barrett  wrote:
> 
> 



> My opinion, I think we need some metric by which to quantify the positive 
> impact against the negative impact otherwise the drag this process has on 
> progress may be discouraging to people joining or staying with this community.
> 
> -Jake
> 

Re: [DISCUSS] CODEOWNERS mechanism feedback

[Anthony Baker]

Hi Alberto!

I haven’t looked at PR review throughput metrics.  I know that is certainly an 
interesting measure to keep an eye on w.r.t to the CODEOWNERS / CODEWATCHERS 
processes.  I think another equally interesting metric is the “quality” of PR 
reviews.  This is difficult to measure but you could think of a continuum such 
as:

Level 0:  I reviewed the PR and gave you a thumbs up just because
Level 1:  I reviewed the PR and I like the names and code formatting
Level 2:  I reviewed the PR and I checked that the change has the intended 
effect
Level 3:  I reviewed the PR and I checked that there is sufficient testing so 
it’s safe to merge
Level 4:  I reviewed the PR and I believe this change is aligned with the goals 
of the project and its architecture

(Of course these are just examples)

If the CODEOWNERS process is moving PR reviews to a higher “level” I could see 
that the time and effort could increase, particularly for complex and large 
changes.  Overall I would argue that’s a good thing for a project like Geode 
that has lots of intrinsic complexity in the source code and domain.  

IMHO,
Anthony


> On Mar 17, 2021, at 8:46 AM, Alberto Gomez  wrote:
> 
> Hi,
> 
> It's been more than two months since the CODEOWNERS file has been in place to 
> automatically add reviewers to pull requests. While we have seen the great 
> benefit of having the experts in the matter being automatically assigned as 
> reviewers to each pull request, I have the feeling that the review process is 
> taking longer now. Some possible reasons could be:
> 1. Some code owners might be getting more reviews than they can cope with and 
> they have become a bottleneck.
> 2. While prior to this change only two approvals were necessary, with the new 
> process the number of approvals from reviewers required to approve a pull 
> request can be much higher than two, depending on the number of areas touched 
> by the PR.
> 
> Again, this might just be my feeling or something incidental and only related 
> to the pull requests I have been working on. In any case, I would like to 
> know if others are experiencing this slowdown in the review of their pull 
> requests.
> 
> Also, I do not know if there are metrics available for the review process. 
> For example, the average time taken since a pull request is submitted or a 
> change is made on it until there is a review. Having these types of metrics 
> would be very useful because they would allow us to evaluate this mechanism 
> from perspectives other than the quality of the reviews and to propose 
> corrective actions if necessary.
> 
> Best regards,
> 
> Alberto

Re: Need Access to apachegeode/geode-native-build on docker hub

[Anthony Baker]

Where are we hosting images for the geode (not the geode-native) pipeline?  
While it might make sense to use the same repo across the board, the images for 
geode-native and geode-site can be useful beyond just CI.  I know I use the 
geode-native-build image to vet releases.

Anthony


> On Feb 22, 2021, at 8:12 AM, Jacob Barrett  wrote:
> 
> This docker image has been there for years and is not related to a release 
> but to the LGTM and Travis builds. I have access and can bump the image for 
> you Mike.
> 
> -Jake
> 
>> On Feb 17, 2021, at 1:35 PM, Owen Nichols  wrote:
>> 
>> apachegeode images on dockerhub correspond to releases. To make a change, 
>> the change must first come to appropriate release branch, then a Geode 
>> release made.
>> 
>> Perhaps trying to use release images for CI is not quite the right strategy?
>> 
>> 
>> ---
>> Sent from Workspace ONE 
>> Boxer
>> 
>> On February 17, 2021 at 1:24:04 PM PST, Mike Martell  
>> wrote:
>> Please provide access to geode-native images on docker hub. Need to update 
>> our latest docker image to support our new open source CI for geode-native. 
>> In particular, need to upgrade to use cmake 3.18.
>> 
>> Thanks,
>> Mike
> 

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

[Anthony Baker]

In my ideal world, the version represents the protocol version and not a 
product release number. As Dan points out, we could add a negotiation option to 
allow more flexibility between clients and servers.

To accomplish this we would need a simpler and well-specified protocol.  The 
current protocol is pretty gnarly and difficult to piece together from the 
implementation.  Complicating this is the fact that the protocol includes not 
only the message definitions but also the data serialization mechanisms for any 
data type included in a message.  Given the challenge of answering “has any 
message or serialization changed?” we've taken the route of using release 
versions.  Perhaps we could build an automated analysis tool that could answer 
this question and reduce frequency of version bumps to match when something 
_really_ changes.

While some work has been done in this direction [1], it’s not far enough along 
to be a viable alternative as yet.

Anthony

[1] https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol



On Jan 29, 2021, at 3:35 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

Well, I have no objection to adding a system property for this if you want to 
try it. Since those properties aren't technically part of the public API I 
don't think we need to offer full support for what happens when the setting 
breaks. I'm just thinking ahead to what will happen when the protocol does 
change. At that point setting the system property will not work, unless the 
client has the capability to negotiate and discover the server version and use 
the old protocol the way that WAN does.

Do keep in mind that failures may not be obvious if the serialization protocol 
changes and your client is pretending to be a different version. I think it's 
possible that the errors might show up only in log messages or corrupted 
values, and only if you are using whatever features are affected by a protocol 
change.

-Dan

From: Alberto Gomez mailto:alberto.go...@est.tech>>
Sent: Friday, January 29, 2021 11:40 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Hi Dan,

Thanks a lot for your comments.

The scope of the RFC is not very ambitious. As I pointed out in it, the idea is 
not to implement the backward compatibility of clients with older servers. 
Rather, the aim is to allow to take advantage of the fact that serialization or 
other types of changes that may break this compatibility are not very frequent. 
For those cases where there have been no incompatible changes, with one of the 
proposed System Properties, it would be possible for a client to communicate 
with an older compatible server without the need of implementing anything 
extra. And we would have the test cases in place to assure this. For those 
cases where compatibility has been broken, it will not be possible to 
communicate the client with the older server and we would also have the tests 
showing that this communication is not possible even if the proposed System 
Property is used.

I do not know how costly it would be to implement and maintain the alternative 
approach you suggest with the negotiation required to support full backward 
compatibility. I would leave that to a different RFC. The good thing is that 
the current RFC could serve as a first step to implement the second, if it is 
agreed that this second feature is worth of being put in Geode.

Best regards,

Alberto

From: Dan Smith mailto:dasm...@vmware.com>>
Sent: Friday, January 29, 2021 1:56 AM
To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

I think just sending the old version will only work until we actually make any 
changes to the protocol. Once we do, serialization will break unless we also 
change the client to pretend to be that old version, including the way it 
serializes and deserializes messages. With this proposal there will be no way 
for the client to use new features with a newer server since the version number 
of the client is set with a system property.

An alternative would be to have the client and the server need a way to 
negotiate which protocol they are going to communicate over. We do this already 
for WAN. WAN senders can be a higher version than receivers, otherwise we 
couldn't upgrade an Active/Active WAN. What happens is that the WAN receiver 
will accept a newer versioned client, and it sends back its own version. The 
client reads the receivers version and adjusts accordingly. You can see this in 
ClientSideHandshakeImpl.handshakeWithServer.

This will require a lot of testing to make sure that users won't see strange 
corruption related errors related to serialization changes.

Re: Geode Client jar dependencies

[Anthony Baker]

I great starting point for Geode micro services is the Spring Boot for Apache 
Geode project [1][2].  It’s already got all the dependencies sorted out.

Anthony

[1] https://github.com/spring-projects/spring-boot-data-geode
[2] https://start.spring.io



On Dec 14, 2020, at 5:48 AM, ankit Soni 
mailto:ankit.soni.ge...@gmail.com>> wrote:

Hello Team,

I am embedding geode (1.12) client lib module (mvn project) inside
microservice  and need to know all mvn dependencies for geode Client. It
would be great help if some share or point me to relevant ref

Thanks in advance.
Ankit

Re: [PROPOSAL] Change the default value of conserve-sockets to false

[Anthony Baker]

Udo, you’re correct that individual servers can set the property independently. 
I was assuming this is more like the ’security-manager` property and others 
that require all cluster members to be in agreement.

I’m not sure I understand the use case to allow this setting to be per-member. 
That makes it pretty challenging to reason about what is happening in a cluster 
when doing root cause analysis. There is even an API to change this value 
dynamically:  
https://geode.apache.org/docs/guide/12/managing/monitor_tune/performance_controls_controlling_socket_use.html

…but I’ve only seen that used to make function threads/sockets follow the 
correct setting.

Anthony


On Nov 20, 2020, at 11:23 AM, Udo Kohlmeyer 
mailto:u...@vmware.com>> wrote:

@Anthony I cannot think of a single reason, why the server should not start up, 
even in a rolling upgrade. This setting should not have an effect on the 
cluster (other than potentially positive). Also, if the Geode were to enforce 
this setting across the cluster, then we have seriously broken our “shared 
nothing value” here..

Re: Requests taking too long if one member of the cluster fails

[Anthony Baker]

Yes, lowering the member timeout is one approach I’ve seen taken for 
applications that demand ultra low latency.  These workloads need to provide 
not just low “average” or even p99 latency, but put a hard limit on the max 
value.

When you do this you need to ensure coherency across at all aspects of timeouts 
(eg client read timeouts and retries).  You need to ensure that GC pauses don’t 
cause instability in the cluster.  For example, if a GC pause is greater than 
the member timeout, you should go back and re-tune your heap settings to drive 
down GC.  If you are running in a container of VM you need to ensure sufficient 
resources so that the GemFIre process is never paused.

All this presupposes a stable and performant network infrastructure.

Anthony


On Nov 21, 2020, at 1:40 PM, Mario Salazar de Torres 
mailto:mario.salazar.de.tor...@est.tech>> 
wrote:

So, what I've tried here is to set a really low member-timeout, which results 
the server holding the secondary copy becoming the primary owner in around 
<600ms. That's quite a huge improvement,
but I wanted to ask you if setting this member-timeout too low might carry 
unforeseen consequences.

Re: [PROPOSAL] Change the default value of conserve-sockets to false

[Anthony Baker]

Question:  how would this work with a rolling upgrade?  If the user did not set 
this property and we changed the default I believe that we would prevent the 
upgraded member from rejoining the cluster.

Of course the user could explicitly set this property as you point out.


Anthony


> On Nov 20, 2020, at 8:49 AM, Donal Evans  wrote:
> 
> While I agree that the potential impact of having the setting changed out 
> from a user may be high, the cost of addressing that change is very small. 
> All users have to do is explicitly set the conserve-sockets value to true if 
> they were previously using the default and they will be back to where they 
> started with no change in behaviour or resource requirements. This could be 
> as simple as adding a single line to a properties file, which seems like a 
> pretty small inconvenience.
> 
> Get Outlook for 
> Android<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=04%7C01%7Cbakera%40vmware.com%7C0f9b5f57066447a0141c08d88d744a67%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414877890840409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=V65jEFWBflK8CWzFgxuFwQBD%2BV2BDlOlPa%2FtLR2N3eY%3Dreserved=0>
> 
> ____
> From: Anthony Baker 
> Sent: Thursday, November 19, 2020 5:57:33 PM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false
> 
> I think there are many good reasons to flip the default value for this 
> property. I do question whether requiring a user to allocate new hardware to 
> support the changed resource requirements is appropriate for a minor version 
> bump. In most cases I think that would come as an unwelcome surprise during 
> the upgrade.
> 
> Anthony
> 
>> On Nov 19, 2020, at 10:42 AM, Dan Smith  wrote:
>> 
>> Personally, this has caused enough grief in the past (both ways, actually!) 
>> that I 'd say this is a major version change.
>> I agree with John. Either value of conserve-sockets can crash or hang your 
>> system depending on your use case.
>> 
>> If this was just a matter of slowing down or speeding up performance, I 
>> think we could change it. But users that are impacted won't just see their 
>> system slow down. It will crash or hang. Potentially only with production 
>> sized workloads.
>> 
>> With conserve-sockets=false every thread on the server creates its own 
>> sockets to other servers. With N servers that's N sockets per thread. With 
>> our default of a max of 800 threads for client connections and a 20 server 
>> cluster you are looking at a worst case of 800 * 20 = 16K sending sockets 
>> per server, with another 16K receiving sockets and 16K receiving threads. 
>> That's before considering function execution threads, WAN receivers, and 
>> various other executors we have on the server. Users with too many threads 
>> will hit their file descriptor or thread limits. Or they will run out of 
>> memory for thread stacks, socket buffers, etc.
>> 
>> -Dan
>> 
> 

Re: [PROPOSAL] Change the default value of conserve-sockets to false

[Anthony Baker]

I think there are many good reasons to flip the default value for this 
property. I do question whether requiring a user to allocate new hardware to 
support the changed resource requirements is appropriate for a minor version 
bump. In most cases I think that would come as an unwelcome surprise during the 
upgrade.

Anthony

> On Nov 19, 2020, at 10:42 AM, Dan Smith  wrote:
> 
> Personally, this has caused enough grief in the past (both ways, actually!) 
> that I 'd say this is a major version change.
> I agree with John. Either value of conserve-sockets can crash or hang your 
> system depending on your use case.
> 
> If this was just a matter of slowing down or speeding up performance, I think 
> we could change it. But users that are impacted won't just see their system 
> slow down. It will crash or hang. Potentially only with production sized 
> workloads.
> 
> With conserve-sockets=false every thread on the server creates its own 
> sockets to other servers. With N servers that's N sockets per thread. With 
> our default of a max of 800 threads for client connections and a 20 server 
> cluster you are looking at a worst case of 800 * 20 = 16K sending sockets per 
> server, with another 16K receiving sockets and 16K receiving threads. That's 
> before considering function execution threads, WAN receivers, and various 
> other executors we have on the server. Users with too many threads will hit 
> their file descriptor or thread limits. Or they will run out of memory for 
> thread stacks, socket buffers, etc.
> 
> -Dan
> 

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

[Anthony Baker]

+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 has concluded?
> 
>From: Robert Houghton 
>Date: Wednesday, November 18, 2020 at 2:07 PM
>To: dev@geode.apache.org 
>Subject: [DISCUSS] Adding CODEOWNERS to Apache Geode
>Hello Devs.
> 
>I would like to improve the quality of the pull-request reviews we see 
> for
>critical parts of the Apache Geode project. In discussions with other
>committers, a (not the) big hurdle to that is getting the right eyes to
>look at a given PR. To that end, I propose the adoption of GitHub's
>CODEOWNERS functionality for the Apache Geode code repository.
> 
>A discussion-document of this issue has been written up
>by @upthewaterspout. Thanks Dan!
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduce%2BCodeowners%2Bfiledata=04%7C01%7Cbakera%40vmware.com%7C9ee8d7fc46874fbb128208d88cbb655c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414083771253757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TFj61EnKBPrO1AfpH6BrVybUjzcnS%2BkymFMo1JxfhxY%3Dreserved=0
> 
>I have tested the feature with fellow Geode committers @upthewaterspout
>and @onichols-pivotal, and found it to meet our expectations.  Please
>review the document, and comment or reply to this thread, by 25 
> November,
>so we might start the task of nominating and applying for ownership.
> 
>-Robert Houghton
> 

Re: apache-geode-1.13.0.tgz not found in LGTM analysis

[Anthony Baker]

Agreed…although snapshots will never be on Apache release mirrors.  We do have 
alternate locations for builds that go through the CI pipelines we could use.

Anthony


On Nov 19, 2020, at 7:55 AM, Jacob Barrett 
mailto:jabarr...@vmware.com>> wrote:

Ideally the develop branches of these other repos should be pulling the last 
good snapshot version and not the last release. If the last release is needed 
there has to be a way to get that version from the Apache mirror process.

Re: needs permission to push code to geode example repo

[Anthony Baker]

Hi Ashish!  The best way to contribute is to open a PR via GitHub.  LMK if you 
need help with that.

What’s your JIRA username?

Anthony


> On Nov 18, 2020, at 10:54 AM, aashish choudhary 
>  wrote:
> 
> Hi Team,
> 
> I am trying to add an example for geode rest api.I have the changes in my
> branch but not sure what is the process to push changes to this repo.Could
> someone help with this?
> 
> Also it seems my permission to raise Jira issue is also revoked. Please
> help with that too.
> 
> With Best Regards,
> Ashish

Re: Apache Geode 1.13.1 patch proposal

[Anthony Baker]

+1 definitely.  Many of the changes are pretty critical—recovery deadlocks and 
TLS communication fixes.

> On Nov 12, 2020, at 11:02 AM, Dan Smith  wrote:
> 
> +1 sounds great!
> 
> From: Dick Cavender 
> Sent: Thursday, November 12, 2020 10:59 AM
> To: dev@geode.apache.org 
> Subject: Apache Geode 1.13.1 patch proposal
> 
> It's been two months since the 1.13.0 release and there have been 28 
> important fixes on support/1.13 that the community would benefit from. Based 
> on this I'd like to propose release of Apache Geode 1.13.1 based on the 
> current support/1.13 branch. I'll volunteer to be the release manager for 
> 1.13.1 so look forward to an RC1 soon.
> 
> -Dick
> 

Re: Please review and contribute: draft of Nov 2020 Apache board report

[Anthony Baker]

Same, thanks Karen!

On Nov 10, 2020, at 10:19 AM, Dave Barnes 
mailto:dbar...@apache.org>> wrote:

LGTM

Re: PR process and etiquette

[Anthony Baker]

I think exploring these additions to PR reviews would be pretty helpful.  It’s 
worth spending the extra time to get a PR right before merging.

Anthony

> On Oct 28, 2020, at 8:40 AM, Robert Houghton  wrote:
> 
> There are some pieces of Apache infrastructure we can control without needing 
> tickets: Specifically
> required_pull_request_reviews:
>dismiss_stale_reviews: true
>require_code_owner_reviews: true
> 
> I think these specific controls could go a long way towards helping keep our 
> PR quality high, while reducing cognitive load for the reviewers.
> 
> Full documentation 
> here
> 

Re: [PROPOSAL] backport GEODE-8651 to 1.13, 9.10, 9.9

[Anthony Baker]

+1 from me

> On Oct 27, 2020, at 2:21 PM, Xiaojian Zhou  wrote:
> 
> Hi, all:
> 
> The fix is to resolve a hang when Connection called notifyHandshakeWaiter the 
> 2nd time and cleared the NioFilter’s unwrapped buffer by mistake.
> 
> The 2nd call should consider if the 1st call has finished handshake. If yes, 
> do nothing. The fix is fully tested and has no risk. This problem exists in 
> earlier versions and should be backported.
> 
> Regards
> 
> Xiaojian Zhou

Fwd: Videos for ApacheCon Are Now Live

[Anthony Baker]

Great news, all the videos from the Geode track for ApacheCon @Home have been 
published [1].  Many thanks to all the speakers!

Anthony

[1] https://www.youtube.com/playlist?list=PLU2OcwpQkYCxKxd7dVETcwEtx5AEDIp1j


Begin forwarded message:

From: Brian Proffitt mailto:b...@apache.org>>
Subject: Videos for ApacheCon Are Now Live
Date: October 23, 2020 at 6:35:08 AM PDT
To: plann...@apachecon.com, 
con...@apache.org
Reply-To: plann...@apachecon.com

All:

On behalf of the ApacheCon organization team, I am pleased to announce that all 
of the videos for ApacheCon @ Home 2020  have now been published on the Apache 
Software Foundation YouTube channel[1]. You are all invited to take a look and 
socialize sessions as you can!

*If* you find any errors, please contact me and (after Oct. 25) Rich Bowen off 
list, and we will see what we can do. To head off the inevitable question: 
session slides will be dealt with separately, so don't ask about them quite 
yet. :)

Many, many thanks go from Rich and I to all the folks who pitched in and helped 
us get these *301 videos across 27 tracks and keynote/plenary sessions*! 
(Perspective: ACAH2020 videos represent 35% of *all* the 855 Apache Software 
Foundation videos to date on YouTube!) No contribution was too small, and 
really helped us get this massive publication done in a timely manner!

Peace,
Brian Proffitt

[1] 
https://www.youtube.com/user/TheApacheFoundation

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

[Anthony Baker]

Given the wide variety of filenames possible do we even need a classification 
scheme?  IOW, why not just take what the user gives us and say thank you :-).  
Is this restriction imposed by our *implementation* choices?

Anthony


> On Oct 7, 2020, at 3:24 PM, Jinmei Liao  wrote:
> 
> Wait, that reason doesn't make much sense either. Dale/Darrel, do you 
> remember why we did what we did?
> 
> On 10/7/20, 3:12 PM, "Jinmei Liao"  wrote:
> 
>I believe we did this for a reason, can't remember exactly what though. 
> Most probably drive by user's existing filenames. I believe we are probably 
> concerned that user's jar name might contain "_" or "-" themselves, like 
> common-logging.jar etc. So we had to resort to finding the first "." followed 
> by a digit to determine where the version pattern begins.
> 
>On 10/7/20, 1:44 PM, "Udo Kohlmeyer"  wrote:
> 
>Hi there Geode Dev List,
> 
>Whilst doing work on 
> GEODE-8466
>  and looking at the functionality that the 
> ClassPathLoader.java,
>  
> JarDeployer.java
>  and 
> DeployedJar.java
>  provide around the “Deploy Jar” functionality, we came across some 
> interesting “supported” filename patterns.
> 
>According to the 
> JarDeployerFileTest.java
>  the “supported” formats are as follows:
> 
>assertThat(JarDeployer.getArtifactId("abc.jar")).isEqualTo("abc");
>assertThat(JarDeployer.getArtifactId("abc-1.jar")).isEqualTo("abc");
>assertThat(JarDeployer.getArtifactId("ab.c.1.jar")).isEqualTo("ab.c");
>
> assertThat(JarDeployer.getArtifactId("abc.v1.jar")).isEqualTo("abc.v1");
>
> assertThat(JarDeployer.getArtifactId("abc-1.0.snapshot.jar")).isEqualTo("abc");
>
> assertThat(JarDeployer.getArtifactId("abc-1.0.v1.jar")).isEqualTo("abc");
>
> assertThat(JarDeployer.getArtifactId("spark-network-common_2.11-2.3.1.jar"))
>.isEqualTo("spark-network-common_2");
>Which don’t make any sense. As the generally accepted norm for a 
> version jar file would be: “[ -  .  .  - 
>  ] .jar”. (note the syntax in red)
> 
>I want to suggest that we DISCONTINUE supporting all jar name formats 
> other than the one mentioned above IMMEDIATELY. As the supported name format 
> is just “funky” but also wrong and can lead to misclassification of the 
> artifact name…. as some of you with a keen eye would have spotted already 
> 
>For those who did not spot the mistake…  
> “spark-network-common_2.11-2.3.1.jar” is incorrectly classified and has the 
> WRONG artifact name. As “spark-network-common_2.11” is the correct artifact 
> name NOT “spark-network-common_2”!
> 
>I would like to introduce this change with 
> GEODE-8466.
>  This would be a “breaking” change, but we should 

Re: [Discussion] RFC to make Geode's working directory configurable

[Anthony Baker]

The plan around backwards compatibility makes sense to me.

Anthony


> On Oct 6, 2020, at 4:10 PM, Dale Emery  wrote:
> 
> Hi Dan,
> 
> I spent more than a week scouring Gradle docs and code for any way to give 
> the parallel forks their own working directories. I couldn't find a way. At 
> least, not through the public API. And I'm reluctant to rely on internal 
> APIs, the way our docker and repeat tests do. If this working-dir idea offers 
> enough resistance, I'll take another look at Gradle.
> 
> Cheers,
> Dale
> 
> On 10/6/20, 3:58 PM, "Dan Smith"  wrote:
> 
>+1
> 
>Looks good to me. If this is just for tests, I suspect there is some 
> gradle way to make parallel forks use different working directories. But 
> having this option in the product doesn't seem like a bad idea.
> 
>-Dan
>
>From: Dale Emery 
>Sent: Tuesday, October 6, 2020 12:12 PM
>To: dev@geode.apache.org 
>Subject: [Discussion] RFC to make Geode's working directory configurable
> 
>Hi all,
> 
>I have submitted an RFC to make Geode’s working directory configurable: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMake%2BGeode%2527s%2BWorking%2BDirectory%2BConfigurabledata=02%7C01%7Cbakera%40vmware.com%7C568729496bb94bbafe4108d86a4d1eeb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637376226749652389sdata=EWrxpNf8TocLKEtapZQP3P5lMvFwuzTVrS9abs2gy%2Fs%3Dreserved=0
> 
>Please review it and comment by Oct 26.
> 
>Cheers,
>Dale
> 
> 

Fwd: [ATTN TRACK CHAIRS] Muse.dev bug bash

[Anthony Baker]

FYI, this might be cool.  Please shout out if you’re interested and then follow 
the contact info below.

Anthony


> Begin forwarded message:
> 
> From: Rich Bowen 
> Subject: [ATTN TRACK CHAIRS] Muse.dev bug bash
> Date: September 24, 2020 at 6:32:09 AM PDT
> To: "plann...@apachecon.com" 
> Reply-To: plann...@apachecon.com
> 
> Track leaders,
> 
> One of our ApacheCon sponsors, MuseDev, is running a Bug Bash for a set of 
> Apache projects. They selected their initial group based on projects they 
> could get their analysis tools without help from the project. While yours 
> wasn’t one of those, they are happy to work with any of our track projects 
> that are in Java/C/C++ and get your project added. They would just need 
> someone familiar with building the project to spend a 30-60 minute zoom 
> working session to help them get their platform successfully building the 
> project.
> 
> FYI, the list of projects selected was:
> 
> Drill
> Shiro
> Storm
> Ignite
> Kafka
> Skywalking
> RocketMQ
> Helix
> Zookeeper
> Groovy
> Karaf
> Lucene-solr
> Royale-compiler
> 
> Presumably, this list was selected because they found sufficiently many 
> problems with them to make it worthwhile to participants.
> 
> If you’re interested, please reach out to their head of engineering, Tom 
> DuBuisson at to...@muse.dev and he’ll work directly with you to get your 
> project set-up for the Bug Bash.
> 
> -- 
> Rich Bowen - rbo...@rcbowen.com
> @rbowen

Re: Clean C++ client metadata in timeouts

[Anthony Baker]

I’m not sure I have answers so I’ll just ask more questions :-)

When a server is killed, does that provoke an asynchronous metadata update to 
clients?  I could be wrong about that but if it IS true, then perhaps we should 
focus on optimizing that path. The sooner that a client can get accurate bucket 
location data the faster it can service requests.

I suggest this because I know that wiping out *all* bucket metadata on the 
client means that we’ve now destroyed the ability of the client to do 
single-hop operations until the metadata is refreshed.  This has the cost of 
additional latency on each client request and the hidden cost of additional 
sockets and threads within the cluster to service the extra hop by forwarding 
requests to the appropriate server.  This is an important because many users 
test and size their geode cluster based on single-hop resource consumption and 
it’s a very steep step up when this is not possible.  If there’s insufficient 
headroom to handle the additional load it can tip a bad situation (single node 
failing) into a much worse cascading condition (multiple nodes failing).

So I guess my questions are:
- What triggers a metadata refresh and how can we make that faster?
- Can we very selectively identify that some metadata is out of date and 
invalidate that information only?


Anthony


On Sep 18, 2020, at 3:50 AM, Alberto Bustamante Reyes 
mailto:alberto.bustamante.re...@est.tech>> 
wrote:

Hi,

Thanks for you messages, here you are some answers:

Dave:
Are there cases in which one or two timeouts are followed by a successful
retry? Or does one timeout *always* end with more timeouts and, ultimately,
an IO error?
Not in our use case, which is kiling a server. In this case, timeouts will end 
up on an IO error.

If a straight-up change solves a constant headache, as you suggest, Alberto, 
and as Blake concurs, that sounds like the way to go. Why introduce a new 
option or property if the user will always prefer one behavior over the other?

The fix works fine for our use case, I suggested the alternatives to make it 
something optional in case there were concerns about it. In other projects I 
have been involved in the past, we had to deal with temporary network problems. 
So most of the times, if a timeout had a consequence (so to say), that was not 
applied after just one timeout.

But its true that in this use case, a timeout always ends up on an IO error, as 
I said. So if you dont see any problem with cleaning the metadata just after 
one timeout, then we dont need any control mechanism for it.



Blake:
Given that attempts to retrieve metadata after the C++ cache is closed are a 
constant headache for Geode Native development, I am generally in favor of 
anything that potentially reduces the number of times/places this happens.  If 
we've failed the handshake, it's very unlikely things will correct themselves 
without outside intervention, so this fix is probably goodness. I'd go ahead 
and submit a PR when you think it's solid.

Good to hear that. The code changes in the draft PR are ready, I just need to 
figure out the testing part. Im not sure how I will add a test because it would 
be the same test as the one added for GEODE-8231...


BR/

Alberto B.



De: Ernie Burghardt mailto:burghar...@vmware.com>>
Enviado: jueves, 17 de septiembre de 2020 22:08
Para: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
Asunto: Re: Clean C++ client metadata in timeouts

Let's please consider how this would controlled and look for ways other than 
YetAnotherProperty

Thanks,
EB

On 9/17/20, 12:59 PM, "Dave Barnes" 
mailto:dbar...@apache.org>> wrote:

   If a straight-up change solves a constant headache, as you suggest,
   Alberto, and as Blake concurs, that sounds like the way to go.
   Why introduce a new option or property if the user will always prefer one
   behavior over the other? (And from a docs perspective, who needs another
   optional property, anyway?)

   On Thu, Sep 17, 2020 at 10:32 AM Blake Bender 
mailto:bbl...@vmware.com>> wrote:

Given that attempts to retrieve metadata after the C++ cache is closed are
a constant headache for Geode Native development, I am generally in favor
of anything that potentially reduces the number of times/places this
happens.  If we've failed the handshake, it's very unlikely things will
correct themselves without outside intervention, so this fix is probably
goodness.  I'd go ahead and submit a PR when you think it's solid.

Thanks,

Blake


On 9/17/20, 9:36 AM, "Dave Barnes" 
mailto:dbar...@apache.org>> wrote:

   Alberto,
   Are there cases in which one or two timeouts are followed by a
successful
   retry? Or does one timeout *always* end with more timeouts and,
ultimately,
   an IO error?
   If timeouts can sometimes be followed by successful retries, and
re-trying
   is the current default behavior, then I agree that introducing a
setting
   that effectively 

[ANNOUNCE] Geode session track for ApacheCon @Home

[Anthony Baker]

HI all,

With conferences going virtual due to current events, we have moved the former 
“Geode Summit” over to a dedicated track as part of the virtual ApacheCon 
event.  Lucky for you, we have some great talk submissions on lots of 
interesting topics!

The talks will be presented live (virtually) on Sept 29-30. You can see the 
talk line up here:
https://www.apachecon.com/acah2020/tracks/

And you can register to attend here (free/donation):
https://hopin.to/events/apachecon-home

Last, check out this primer from Bob Glithero:
https://twitter.com/ApacheGeode/status/1293967391467036673?s=20


I’ll see you there!

Anthony

Re: JIRA issues for geode native developers

[Anthony Baker]

FWIW -

Mike is listed on the committer roles of Geode [1].
Matthew is not yet.

We typically offer JIRA permissions anytime someone asks to make it easier for 
them to contribute.

Anthony

[1] https://whimsy.apache.org/roster/committee/geode


On Aug 21, 2020, at 12:06 PM, Dan Smith 
mailto:dasm...@vmware.com>> wrote:

It looks like they weren’t listed as committers in JIRA. I added them, you 
should be able to assign them issues now!

-Dan

On Aug 21, 2020, at 11:00 AM, Blake Bender 
mailto:bbl...@vmware.com>> wrote:

Hello,

In the course of attempting to be a better Geode citizen yesterday, I attempted 
to assign a JIRA issue to one of the members of the geode native full-time dev 
team, and discovered that I couldn’t.  In fact, neither of them (Mike Martell, 
Matthew Reddington) can be assigned GEODE JIRA issues.  Does anyone know what 
setting/permission/etc is missing there, and how to fix?

Thanks,

Blake

Re: Draft of August 2020 Geode report to the board

[Anthony Baker]

Nice!

I would also call out a significant increase in (awesome) community blog posts:

https://medium.com/p/threads-used-in-apache-geode-function-execution-9dd707cf227c?source=email-9fb0d2d72e25--writer.postDistributed=bfb9703d4399c681a447389c689094af
https://medium.com/@luckycjx/improving-the-performance-of-apache-geode-persistence-recovery-af08918d2ef?source=friends_link=850d19f929b7c54275a18a2ad43ba6d7
https://medium.com/@boglesby_2508/calculating-the-size-of-an-apache-geode-region-5ffb3b141464
https://medium.com/@jujoramos/geode-write-behind-event-handling-with-spring-jpa-a54f17e19709
https://medium.com/@boglesby_2508/verifying-apache-geode-region-consistency-in-different-distributed-systems-e15d6edfe15d
https://medium.com/@boglesby_2508/logging-apache-geode-gatewaysender-queue-events-e7e19937a542
https://medium.com/@jujoramos/spring-security-geode-4670faff47a0

Perhaps also highlight that several RFC’s are seeing significant discussion 
and/or activity including:

- WAN Configuration for an Ingress Proxy
- Avoid the queuing of dropped events by the primary gateway sender when the 
gateway sender is stopped
- Geode Redis API Improvements, 
- Modularization / Classloader Isolation
- Support for clear operation on partitioned region


Anthony


> On Aug 7, 2020, at 11:00 AM, Karen Miller  wrote:
> 
> Here's a first draft of a board report.  I'd like to include some of the
> project's many blog posts (any new videos? did anyone give a Geode talk at
> a workshop or conference?) in our Community Health section.  Please send me
> a link and hopefully an approximate date when the blog was posted.
> 
> Please approve or get me additions/corrections before Monday August 10 at
> noon Pacific time, so I can file our report on time.
> Thanks.  Karen
> 
> ## Description:
> The mission of Apache Geode is the creation and maintenance of software
> related
> to a data management platform that provides real-time, consistent access to
> data-intensive applications throughout widely distributed cloud
> architectures.
> 
> ## Issues:
> There are no issues requiring board attention.
> - 309 issues opened in JIRA, past quarter (-3% decrease)
> - 244 issues closed in JIRA, past quarter (1% increase)
> 
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (4 years ago)
> There are currently 109 committers and 54 PMC members in this project.
> 
> Community changes, past quarter:
> - No new PMC members. Last addition was Alexander Murmann on 2020-03-26.
> - No new committers. Last addition was Mario Kevo on 2020-03-23.
> 
> ## Project Activity:
> We're actively working on the version 1.13 release, with many discussions
> over code inclusions that delay the release, but provide a higher quality
> product.
> 
> ## Community Health:
> The Apache Geode dev mailing list had a 26% decrease in traffic, while the
> issues mailing list experienced a 32% increase in traffic in Q2.
> 
> We are planning a Geode content track for ApacheCon @Home.  We have two days
> of content based on submissions from the community.

Re: [PROPOSAL] one-time cleanup of stray and obsolete tags in geode repo

[Anthony Baker]

+1 with the exception of sga2-core.  IIRC that is related to a code donation 
and should be preserved.  All other tags you’ve listed seem reasonable to 
remove.  I believe that tags in the rel/* are protected and will require an 
INFRA ticket.

Anthony


> On Jul 30, 2020, at 12:21 AM, Owen Nichols  wrote:
> 
> Tags in the rel/ namespace should be created by the Geode release manager as 
> part of an official Geode release only, yet we seem to have some extra ones 
> somehow.
> Further, I don't see any value in keeping RC tags forever long after the 
> release is final.
> 
> Please vote +1 in favor of trimming the current list of 110 tags down to 20 
> to make it nice and easy for newcomers (as well as the rest of us) to find 
> and checkout a specific version of Geode; otherwise vote -1.  If the majority 
> vote is +1 at 3PM PDT Fri Aug 7, I will proceed to archive and delete the 90 
> unnecessary tags as detailed below.
> 
> I propose to KEEP only the following tags, corresponding to official Geode 
> releases:
> 
> rel/v1.12.0
> rel/v1.11.0
> rel/v1.10.0
> rel/v1.9.2
> rel/v1.9.1
> rel/v1.9.0
> rel/v1.8.0
> rel/v1.7.0
> rel/v1.6.0
> rel/v1.5.0
> rel/v1.4.0
> rel/v1.3.0
> rel/v1.2.1
> rel/v1.2.0
> rel/v1.1.1
> rel/v1.1.0
> rel/v1.0.0-incubating
> rel/v1.0.0-incubating.M3
> rel/v1.0.0-incubating.M2
> rel/v1.0.0-incubating.M1
> 
> I propose a one-time cleanup to DELETE all other tags, specifically:
> 
> develop/highwater
> modules-pre-merge
> rel/v1.0.0-incubating.M1.RC1
> rel/v1.0.0-incubating.M1.RC2
> rel/v1.0.0-incubating.M2.RC1
> rel/v1.0.0-incubating.M2.RC2
> rel/v1.0.0-incubating.M3.RC1
> rel/v1.0.0-incubating.M3.RC2
> rel/v1.0.0-incubating.M3.RC3
> rel/v1.0.0-incubating.M3.RC4
> rel/v1.0.0-incubating.M3.RC5
> rel/v1.0.0-incubating.M3.RC6
> rel/v1.0.0-incubating.M3.RC7
> rel/v1.0.0-incubating.RC1
> rel/v1.0.0-incubating.RC2
> rel/v1.1.0.RC1
> rel/v1.1.0.RC2
> rel/v1.1.0manualrev-2017-02-16
> rel/v1.1.0manualrev-2017-10-19
> rel/v1.1.1.RC1
> rel/v1.1.1.RC2
> rel/v1.10.0.1
> rel/v1.10.0.1.RC1
> rel/v1.10.0.2
> rel/v1.10.0.RC1
> rel/v1.10.0.RC2
> rel/v1.11.0.1
> rel/v1.11.0.2
> rel/v1.11.0.23755
> rel/v1.11.0.23755_2
> rel/v1.11.0.23755_3
> rel/v1.11.0.3
> rel/v1.11.0.4
> rel/v1.11.0.5
> rel/v1.11.0.6
> rel/v1.11.0.7
> rel/v1.11.0.7565
> rel/v1.11.0.8
> rel/v1.11.0.RC1
> rel/v1.11.0.RC2
> rel/v1.11.0.RC3
> rel/v1.11.0.RC4
> rel/v1.12.0.1
> rel/v1.12.0.1234
> rel/v1.12.0.2
> rel/v1.12.0.23755
> rel/v1.12.0.3
> rel/v1.12.0.4
> rel/v1.12.0.5
> rel/v1.12.0.6
> rel/v1.12.0.RC1
> rel/v1.12.0.RC2
> rel/v1.12.0.RC3
> rel/v1.12.0.RC4
> rel/v1.14.0.23755
> rel/v1.2.0.RC1
> rel/v1.2.0.RC2
> rel/v1.2.1.RC1
> rel/v1.2.1.RC2
> rel/v1.2.1.RC3
> rel/v1.2.1.RC4
> rel/v1.2.1manualrev-2017-10-19
> rel/v1.3.0.RC1
> rel/v1.3.0.RC2
> rel/v1.3.0.RC3
> rel/v1.3.0.RC4
> rel/v1.4.0.RC1
> rel/v1.4.0.RC2
> rel/v1.5.0.RC1
> rel/v1.5.0.RC2
> rel/v1.6.0.RC1
> rel/v1.7.0.RC1
> rel/v1.7.0.RC2
> rel/v1.8.0.RC1
> rel/v1.8.0.RC2
> rel/v1.9.0.1
> rel/v1.9.0.1.RC1
> rel/v1.9.0.2
> rel/v1.9.0.RC1
> rel/v1.9.0.RC2
> rel/v1.9.0.RC3
> rel/v1.9.0.RC4
> rel/v1.9.1-nordix
> rel/v1.9.1.RC1
> rel/v1.9.1.RC2
> rel/v1.9.1.RC3
> rel/v1.9.2.RC1
> sga2-core
> v1.1.0manualrev-2017-10-19
> v9.0.0-beta.1

Re: [VOTE] change Default branch for geode-examples to 'develop'

[Anthony Baker]

-1.  Happy to change my mind if there’s a user-friendly way to deal with the 
scenario I mentioned below.

Anthony


On Jul 14, 2020, at 8:40 AM, Owen Nichols 
mailto:onich...@vmware.com>> wrote:

Hi Anthony, there is a separate discuss thread [1] for this topic.  This is the 
vote thread for the ASF INFRA ticket [2] to make this one specific change that 
came out of the discussion.  Your input is valuable and I encourage you to both 
vote on this thread and continue the conversation on the discuss thread.

[1] 
https://lists.apache.org/thread.html/rfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%3Cdev.geode.apache.org%3E
[2] https://issues.apache.org/jira/browse/INFRA-20510


On 7/14/20, 7:16 AM, "Anthony Baker" 
mailto:bak...@vmware.com>> wrote:

   Consider the use case of an application developer who wants to run 
geode-examples against the latest geode release:

   1) brew install apache-geode
   2) git clone geode-examples
   3) Get some runtime errors because geode-examples won’t connect to a 
previous geode release

   At this point, you have to do some detective work to either download the 
geode-examples from the corresponding source release or switch over to the 
appropriate git tag.

   I think there’s value in maintaining a default branch of geode-examples that 
tracks the latest release.


   Anthony


On Jul 9, 2020, at 9:39 PM, Owen Nichols 
mailto:onich...@vmware.com>> wrote:

A fresh checkout of geode and all but one geode- repos checks 
out develop as the Default branch.

The lone exception is geode-examples.  Please vote +1 if you are in favor of 
changing its Default branch to develop for consistency with the other repos and 
other reasons as per recent discussion[1].

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Cbakera%40vmware.com%7Ce9db02c2e21544dc02e608d8280c43d6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637303380464893583sdata=1dCB0szNtuImpKWBSaL9ntHFY6z1KCVJWusiT5%2BEO0I%3Dreserved=0

Re: [VOTE] change Default branch for geode-examples to 'develop'

[Anthony Baker]

Consider the use case of an application developer who wants to run 
geode-examples against the latest geode release:

1) brew install apache-geode
2) git clone geode-examples
3) Get some runtime errors because geode-examples won’t connect to a previous 
geode release

At this point, you have to do some detective work to either download the 
geode-examples from the corresponding source release or switch over to the 
appropriate git tag.

I think there’s value in maintaining a default branch of geode-examples that 
tracks the latest release.


Anthony


> On Jul 9, 2020, at 9:39 PM, Owen Nichols  wrote:
> 
> A fresh checkout of geode and all but one geode- repos checks 
> out develop as the Default branch.
> 
> The lone exception is geode-examples.  Please vote +1 if you are in favor of 
> changing its Default branch to develop for consistency with the other repos 
> and other reasons as per recent discussion[1].
> 
> [1] 
> https://lists.apache.org/x/thread.html/rfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee@%3Cdev.geode.apache.org%3E

Re: Flaky test caused by missing JDK dependency

[Anthony Baker]

I thought we made the dependency on the Attach API optional when we added 
support for JDK 11?

Anthony


> On Jul 8, 2020, at 10:17 AM, Kirk Lund  wrote:
> 
> To transition away from Attach API, the community needs a proposal to do so
> and we'll need to deprecate the GFSH options that depend on Attach API such
> as "--pid" in "status server --pid 20938". Even then we're looking at a
> minimum of one major release before we can remove options after they are
> deprecated.
> 
> We haven't had a major release in 4+ years so don't hold your breath! :)
> 
> On Wed, Jul 8, 2020 at 9:59 AM Sean Goller  wrote:
> 
>> The Liberica JDK does not include the Attach API. I'm investigating why.
>> Given the inherent insecurity of this API, I recommend we transition away
>> from using it.
>> 
>> From: Kirk Lund 
>> Sent: Monday, July 6, 2020 10:36 AM
>> To: dev@geode.apache.org 
>> Subject: Flaky test caused by missing JDK dependency
>> 
>> CI Failure:
>> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles
>> failed with ConditionTimeoutException
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6183data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=g67yHspVjXA8pJjp0shhYf7fZWltB7EexUXJ6sck8F8%3Dreserved=0
>> 
>> I've debugged the latest occurrence of GEODE-6183 (intermittent failure
>> CI):
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main%2Fjobs%2FWindowsCoreIntegrationTestOpenJDK11%2Fbuilds%2F34data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=bACP7X6c%2By%2FtzyN6S65UEJ0xWRYxgEhM1KyvlYaYbSU%3Dreserved=0
>> 
>> The underlying cause is a missing dependency: the Attach API. In the Oracle
>> JDK, the Attach API is found in the JAVA_HOME/lib/tools.jar. In some JDKs,
>> including LibericaJDK, there may not be a tools.jar or it may be missing
>> from our image of specific JDKs or a specific OS. I confirmed that the
>> Attach API is actually inside a different .jar on some Mac releases of the
>> JDK.
>> 
>> Other than JDK differences, I'm not sure why tools.jar would intermittently
>> be missing from our testing image, but that's definitely the cause of
>> WindowsCoreIntegrationTestOpenJDK11 failing. I've reviewed a couple other
>> older runs and it was the same intermittent cause of failure.
>> 
>> Does anyone know if LibericaJDK includes tools.jar or the Attach API?
>> 
>> Does anyone know how to verify that our images all have tools.jar or its
>> equivalent?
>> 
>> java.util.ServiceConfigurationError:
>> com.sun.tools.attach.spi.AttachProvider: Provider
>> sun.tools.attach.WindowsAttachProvider not found
>> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
>> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
>> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
>> at
>> 
>> jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
>> at
>> 
>> jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
>> at
>> 
>> org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
>> at
>> 
>> org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
>> at
>> 
>> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
>> at
>> 
>> org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:92)
>> 

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

[Anthony Baker]

Another option is JMX, see 
https://geode.apache.org/docs/guide/19/managing/management/list_of_mbeans.html.

Anthony


On Jul 8, 2020, at 9:24 AM, Jacob Barrett 
mailto:jabarr...@vmware.com>> wrote:

Steve,

Geode is in a transition from its on disk proprietary stats format to utilizing 
Micrometer.io.
 Some of what you are looking for may already be exposed via Micrometer. If so 
you can just use whatever registry of your choice to publish those stats. If 
the metric you need is not converted to Micrometer its pretty easy in most 
cases to refactor it and we would welcome a JIRA or even better a PR.

-Jake


On Jul 7, 2020, at 9:58 PM, steve mathew 
mailto:steve.mathe...@gmail.com>> wrote:

Hello Geode Dev and users

We have a requirement to constantly monitor the resource utilization (Disk
and Heap usage) for the cluster nodes from external processes.
Seeking help to understand the recommended way (or APIs available ) to get
this in a separate process...We need to trigger some actions/custom logic
if it goes above some threshold..

Thanks
Steve.

Re: about Liberica JDK

[Anthony Baker]

Liberica is an OpenJDK distribution like AdoptOpenJDK, Oracle, RedHat, Amazon, 
Azul, etc.  I have yet to find a behavioral difference between the 
distributions—it’s mostly about ease of acquiring binaries and LTS support. 
Just for simplicity I would prefer to use a single JDK distribution across 
versions in our CI pipelines.


Anthony


> On Jul 7, 2020, at 2:21 AM, Alberto Bustamante Reyes 
>  wrote:
> 
> Hi devs,
> 
> I have seen in develop branch this commit that changes openjdk by Liberica 
> JDK ( 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5312data=02%7C01%7Cbakera%40vmware.com%7C92aa27c47a164abdd6b808d822573a33%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637297105319626477sdata=X3V4jcQ7DWEVtJuUaXOQy%2F0l3xri9g4a0%2BfflLmui1g%3Dreserved=0
>  ), although it was reverted later so I suppose there are still issues to be 
> solved.
> 
> I didn't know Liberica and I'm curious about the change. Why is this change 
> being implemented?
> 
> BR/
> 
> Alberto B.
> 

Exciting news: Geode Summit + ApacheCon @Home

[Anthony Baker]

Hi everyone!

Earlier this year VMware announced a Geode Summit as part of SpringOne [1]. 
Well, a lot has happened since then! Many tech conferences have gone virtual 
and SpringOne is no exception [2]. SpringOne is a great conference with a lot 
of excellent content. Unfortunately they have a limited amount of sessions and 
because of that it makes more sense to move the Geode Summit to an alternate 
“virtual” venue.

The great news is, this gives us a fantastic opportunity to showcase Geode 
during the ApacheCon @Home virtual event! [3][4], We can host an entire track 
of sessions dedicated to Geode during the 72h event from September 29, 2020 
through October 1, 2020. The CFP is open for one more week and the more great 
content we have the more sessions we can host!

What you need to do:

1) Register for ApacheCon @Home [5]
2) Submit your talk ASAP [6]

The CFP closes on Monday, July 13th, 2020 8:00 AM (America/New_York time - UTC 
-5).  If you have already submitted a Geode talk for ApacheCon, please let me 
know.  If you had previously submitted a talk for the Geode Summit you will 
need to resubmit that for ApacheCon (thank you and please let me know as well).

All kinds of Geode talks are welcome:

- How I used Geode in my Application
- How I made a contribution to the Geode project
- How I made Geode integrate with project XYZ
- How Geode works under the hood
- How I configure Geode for my application workload
- Etc.


Thanks,
Anthony


[1] 
https://lists.apache.org/thread.html/r67505cbc739b6064db515dfb44c024ea7c1b3c98e763c85ce91881a3%40%3Cuser.geode.apache.org%3E
[2] https://springone.io
[3[ https://apachecon.com/acna2020/
[4] 
https://lists.apache.org/thread.html/r7c688d0488f5a3960453bc39bc388ea1a7dacc5db6b6c2254641fb45%40%3Cannounce.apachecon.com%3E
[5] https://hopin.to/events/apachecon-home
[6] https://apachecon.com/acah2020/cfp.html

Re: Us vs Docker vs Gradle vs JUnit

[Anthony Baker]

When evaluating technical alternatives I think it’s helpful to look at data.  
Has anyone recently tried to run the entire dunit test suite in parallel w/o 
docker?  How many tests need to be changed?  IIRC, there would be non-trivial 
work in product code around statics and system properties as well.

Maybe pursuing a dual short-term / long-term approach ends up being the most 
realistic approach.  

@Jake have you tried using the testcontainer project with dunit?  Maybe it’s 
possible to use GenericContainer with an open RMI port.

Anthony


> On Jun 30, 2020, at 1:20 PM, Donal Evans  wrote:
> 
> +1 for fixing the tests. It'll be a lot of work, but it'll only be a lot of 
> work once, as opposed to taking on maintenance of our own custom Docker 
> plugin, which will be an ongoing effort and not at all immune from getting 
> broken again at some point in the future.
> 
> From: Jinmei Liao 
> Sent: Tuesday, June 30, 2020 12:28 PM
> To: dev@geode.apache.org 
> Subject: Re: Us vs Docker vs Gradle vs JUnit
> 
> I would vote for fixing the tests to use gradle's normal forking. If we are 
> going to invest time and effort, let's invest in an option that can reduce 
> our dependencies
> 
> From: Jacob Barrett 
> Sent: Tuesday, June 30, 2020 11:30 AM
> To: dev@geode.apache.org 
> Subject: Us vs Docker vs Gradle vs JUnit
> 
> All,
> 
> We are in a bit of a pickle. As you recall from a few years back in an effort 
> to both stabilize and parallelize integration, distributed and other 
> integration/system like test we use Docker. Many of the tests reused the same 
> ports for services which cause them to fail or interact with each other when 
> run in parallel. By using Docker to isolate a test we put a bandage on that 
> issue. The plugin overrides Gradle’s default forked runner by starting the 
> runners in Docker containers and marshaling the execution parameters to those 
> Dockerized runners.
> 
> The Docker test plugin is effectively unmaintained. The author seems content 
> on keeping it compatible with Gradle 4. We forked it to work with Gradle 5 
> and various other issues we have hit over the years. We have shared patches 
> in the past with little luck in having them merged and still its only 
> compatible with Gradle 4.8 at best. I spent some time trying to port it to 
> Gradle 6 but its going to be a larger undertaking given that Gradle 6 is 
> fully Java modules compatible. They added new members throughout to handle 
> modules in addition to class paths.
> 
> Long story short because our tests can’t be parallelized without a container 
> system we are stuck. We can’t go to JUnit 5 without updating Docker plugin 
> (potentially minor changes). We can’t go to Gradle 6 without updating the 
> Docker plugin (potentially huge changes). Being stuck is not a good place. I 
> see two paths out of this:
> 
> 1) We buckle down and fix the tests so they can run in parallel via the 
> normal forking mechanism of Gradle. I know some effort has been expended in 
> this by using our new rules for starting servers. We should need to go 
> further.
> 
> 2) Fully invest in the Docker plugin. We would need to fork this off as a 
> fully maintain sub-project of Geode. We would need to add to it support for 
> both Gradle 6 and JUnit 5.
> 
> My money is on fixing the tests. It is clear, at least from my exhaustive 
> searching, nobody in the Gradle and JUnit communities are isolating their 
> tests with containers. They are creating containers to host service for 
> system level testing, see Testcontainers project. The tests themselves run in 
> the local kernel space (not in container).
> 
> We made this push in the C++ and .NET tests, a much smaller set of tests, and 
> it works great. The framework takes care to create clusters that do not 
> interact with each other on the same host. Some things in Geode make this 
> harder than others, like http service not support ephemeral port selection, 
> and gfsh not providing machine readable output about ephemeral port 
> selections. We use port knocking to prevent the OS from assigning the port 
> ephemerally to another process. The framework knocks, opens and then closes, 
> all the ports it needs for the server/locator services and starts them 
> explicitly on those ports. Because of port recycling rules in the OS another 
> ephemeral port request won’t get those ports for some time after they are 
> closed. It's not perfect but it works. Fixing Geode to support ephemeral port 
> selection and a better reporting mechanisms for those port choices would be 
> more ideal. Also, we only start services necessary for the test, like don’t 
> start the http ports if they aren’t going to be used.
> 
> I would love some feedback and thoughts on this issue. Does anyone else see a 
> different path forward?
> 
> -Jake
> 
> 
> 
> 
> 

Re: Fate of master branch

[Anthony Baker]

By just do it, I assume you mean:

- Contact delete master where not needed
- Rename master to main when needed
- Contact INFRA to change the default branch
- Update README and CI jobs as needed

Across *all* geode repos.


Anthony


> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
> 
> +1 to delete. No good reason to keep it that I know of. I think I am the 
> third +1 with no -1s so just do it.
> 
> Thanks,
> Mark
> 
>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  wrote:
>> 
>> +1 to deleting. Given we tag everything properly on the other branches, I
>> don't see the need for it either.
>> 
>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>  wrote:
>> 
>>> +1 for deleting master branch. An also for updating the wiki page about
>>> branching that Alberto pointed out.
>>> 
>>> De: Bruce Schuchardt 
>>> Enviado: viernes, 26 de junio de 2020 17:37
>>> Para: dev@geode.apache.org 
>>> Asunto: Re: Fate of master branch
>>> 
>>> Let's just delete it.  I need to do that in my own repos as well.
>>> 
>>> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>>> 
>>>   Apologies if this has been addressed already and I missed it.  In
>>> keeping with other OSS projects, I believe it’s time we did something about
>>> removing the insensitive term master from Geode repositories.
>>> 
>>>   One choice a lot of projects appear to be going with is a simple
>>> rename from master • main.  In our own case, however, master isn’t really
>>> in use for anything vital.  We track releases with a tag and a branch to
>>> backport fixes to, and the develop branch is the “source of truth”
>>> latest-and-greatest version of the code.  We could thus simply delete
>>> master with no loss I’m aware of.  Any opinions?
>>> 
>>>   Thanks,
>>> 
>>>   Blake
>>> 
>>> 
>>> 
> 

Re: Fate of master branch

[Anthony Baker]

Let’s check all the repos:

geode
master is the latest released code
work is done on develop (default branch)

geode-benchmarks
master is the latest released code
work is done on develop (default branch)

geode-dotnet-core-client
master is the latest released code
work is done on develop (default branch)

geode-native
master is the latest released code
work is done on develop (default branch)

geode-site
asf-site is the CMS branch for publishing
work is done on master (default branch)

geode-examples
master is the default branch and latest release
work is done on develop

geode-kafka-connector
work is done on master (default branch)


For some repos, removing `master` entirely seems pretty low impact.  

Side note:  when I work in other projects it’s always nice to `git clone XXX` 
and be working on a known good branch.  For the geode repo the default branch 
is develop so that doesn’t really apply—it’s just as much friction to checkout 
main as rel/v1.12.0.  

For geode-examples, there is more impact since master is the default branch and 
anyone who has accessed these examples would be affected.  I think it’s still 
worth it to make the switch.

Are there any effects on CI jobs?  README files?


Side node #2:  GitHub has suggested they will be supporting this name change, 
but the details of when and how are unclear.  And other Apache projects are 
moving in this direction as well.

Anthony


> On Jun 26, 2020, at 8:37 AM, Bruce Schuchardt  wrote:
> 
> Let's just delete it.  I need to do that in my own repos as well.
> 
> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
> 
>Apologies if this has been addressed already and I missed it.  In keeping 
> with other OSS projects, I believe it’s time we did something about removing 
> the insensitive term master from Geode repositories.
> 
>One choice a lot of projects appear to be going with is a simple rename 
> from master • main.  In our own case, however, master isn’t really in use for 
> anything vital.  We track releases with a tag and a branch to backport fixes 
> to, and the develop branch is the “source of truth” latest-and-greatest 
> version of the code.  We could thus simply delete master with no loss I’m 
> aware of.  Any opinions?
> 
>Thanks,
> 
>Blake
> 
> 

Re: Odg: Certificate Based Authorization

[Anthony Baker]

That’s fine, I just want to understand what happens when I use this API:

createdAuthenticatedView(…)

Does it throw an exception?  Silently work but not switch to the new user?


Thanks,
Anthony


On Jun 19, 2020, at 10:14 AM, Jacob Barrett 
mailto:jabarr...@vmware.com>> wrote:

1) Multi-user authentication will not be supported when using this new kind of 
SecurityManager implementation.

I agree here. What we are implementing is application/service level 
authentication. Using certs from the applications connection is not viable for 
multi-user authentication. A method similar to option 2 below would need to be 
implemented for such a thing. (See comments below on option 2 issues)

Re: Odg: Certificate Based Authorization

[Anthony Baker]

Hi Mario, just curious if you’ve made any progress on this as of yet.  I have a 
few questions:

1) What is the implication for multi-user auth? Would this just become a no-op 
for this kind of SecurityManager implementation?  See [1][2].

2) I’m not sure that the CN is sufficiently general.  What if I want to use the 
SAN for the Principal?  Can we forward the entire certificate to the the 
authenticate [3] callback?


Anthony

[1] 
https://geode.apache.org/docs/guide/19/basic_config/the_cache/managing_a_multiuser_cache.html
[2] 
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCache.html#createAuthenticatedView-java.util.Properties-
[3] 
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html#authenticate-java.util.Properties-


On Dec 6, 2019, at 9:06 AM, Jens Deppe (Pivotal) 
mailto:jde...@pivotal.io>> wrote:

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 
mailto:mario.k...@est.tech>> 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 

Re: [INFO] Distributed Test runs in bulk results.

[Anthony Baker]

Thanks Mark!  Can you highlight any surprises in these results compared to 
previous runs?

Anthony


> On Jun 10, 2020, at 10:59 PM, Mark Hanson  wrote:
> 
> Hello All,
> 
> I have been doing bulk test runs of DistributedTestOpenJDK8, in this case 
> over 200. Here is a simplified report to kind of help you see what I am 
> seeing and I think everybody sees with random failures as part of the PR 
> process.
> 
> It is very easy to cause failures like this by not knowing what is running 
> asynchronous and Geode is a complex system or introducing timing constraints 
> that may not hold up in the system e.g. waiting 5 seconds for a test result 
> that could take longer unbeknownst you.
> 
> All of that said, here are the results. There are tickets already open for 
> most if not all of these issues.
> 
> Please let me know how often you all would like to see these reports…
> 
> Thanks,
> Mark
> 
> 
> ***
> Overall build success rate: 84.0%
> 
> 
> The following test methods see failures in more than one class.  There may be 
> a failing *TestBase class
> 
> *.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>   18 failures :
>  ParallelWANPersistenceEnabledGatewaySenderDUnitTest:  7 failures (96.889% 
> success rate)
>  ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  11 failures 
> (95.111% success rate)
> 
> *.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived:
>   4 failures :
>  SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest:  3 failures 
> (98.667% success rate)
>  SerialWANPersistenceEnabledGatewaySenderDUnitTest:  1 failures (99.556% 
> success rate)
> 
> ***
> 
> 
> org.apache.geode.management.MemberMXBeanDistributedTest:  3 failures (98.667% 
> success rate)
> 
> testBucketCount   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3247data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730317409sdata=HRdBnvmthfuddRqVjC8T9EzMufHQ1959MIAcPzJINm0%3Dreserved=0
> testBucketCount   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3241data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730327404sdata=DxqiSO%2BbdLgvEND5SdqiWUu8vpKGhNsOvKhWjFydxDA%3Dreserved=0
> testBucketCount   
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3199data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730327404sdata=ZhrecVfpX9T5NJMFsuxhU0QQbx3LwJx3QjVzK3EvXbo%3Dreserved=0
> 
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest:
>   7 failures (96.889% success rate)
> 
> 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived  
>  
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3335data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730327404sdata=NzB40k6LwF5cj5D20XL7CyOO7eGAQHuWe0MUzfDKn%2BM%3Dreserved=0
> 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived  
>  
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3331data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730327404sdata=%2F4x18mauNSUWf5wng3AU%2B0RNjrMoa0M9X5hfohbf47I%3Dreserved=0
> 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived  
>  
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-mass-test-run-main%2Fjobs%2FDistributedTestOpenJDK8%2Fbuilds%2F3294data=02%7C01%7Cbakera%40vmware.com%7Cfddc96a2b1da4176784508d80dcc9bf6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637274519730327404sdata=O7rOO971KGc2nUS3I6yAFlKDnmcTEJPIiLDmuAw%2B4Q0%3Dreserved=0
> 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived  
>  
> 

Re: [PROPOSAL] make Cluster Management Service CRUD operations thread safe

[Anthony Baker]

I think the first question to answer is:  can simultaneous updates to 
configuration be made safely?  Or what is the critical section of code that 
needs to be protected?

Another thing to consider with dlocks is what happens in the failure case when 
the lock is not properly released.  Does it continue to block all management 
/configuration operations?  Does it expire after a period of time?

Anthony


> On May 28, 2020, at 10:17 AM, Jinmei Liao  wrote:
> 
> The proposal is proposing using ONE single dlock to synchronize all CMS CRUD 
> operations, that means, in a given time, only one CRUD operation in CMS is 
> allowed in the entire cluster, this seems a bit too harsh.
> 
> Another way is to use a dlock per ID to only synchronize CRUD operation on 
> the same ID element. That way, we allow more concurrency. I am just not sure 
> what's the cost of creating a dlock. Is the the cost of creating a dlock per 
> ID warrants the performance gain?
> 
> Comment/Suggestions?
> 
> Jinmei
> 
> From: Jinmei Liao 
> Sent: Tuesday, May 26, 2020 1:02 PM
> To: dev@geode.apache.org 
> Subject: [PROPOSAL] make Cluster Management Service CRUD operations thread 
> safe
> 
> Hi, Geode Community,
> 
> Currently, the CMS CRUD operations are not thread safe, if one call tries to 
> create a region, and another call tries to delete the same region, if timing 
> is off, we could end up with inconsistent state (what's in cluster config and 
> what's actually on the server). So we should make these operations thread 
> safe. Here is the proposal to try to achieve it:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMake%2BCluster%2BManagement%2BService%2528CMS%2529%2BThread%2BSafedata=02%7C01%7Cbakera%40vmware.com%7C08663df2f1c846dddaaf08d8032d9d8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637262841746056995sdata=eayoO7sOyyFgSsOP%2FXiN2U1L5YTbbukmBVkVmXtR3jI%3Dreserved=0
> 
> Comments/suggestions welcome.
> 
> Jinmei