Re: Github actions - Integration tests

[Dan Smith]

That ConcurrentTestRunnerTest is testing a test utility to see if it can catch 
race conditions. We didn't end up using that utility as much as I thought we 
might. You could consider just ignoring/deleting that test.

-Dan

From: Sai Boorlagadda 
Sent: Tuesday, February 7, 2023 5:56 PM
To: dev@geode.apache.org 
Subject: Re: Github actions - Integration tests

!! External Email

Integration tests pass consistently after configuring the
`--max-workers=12` and by not setting the `testMaxParallelForks` (so it
defaults to max-workers/4), except for one test[1] which is a test called
ConcurrentTestRunnerTest to test the ConcurrentTestRunner.

This test is expected to fail when an atomic int is modified in parallel
threads. This ensures ConcurrentTestRunner is running in parallel, but
unfortunately, Github actions may be running with a single core
(availableProcessors = 2). The logs are available in the summary section
and saved for up to 5 days.

Though the available processors are 2 and it seems the atomic int is never
got executed in parallel. Any thoughts?

@Dan Tagging you as you were the original author to little bit understand
about this test.

Available processors: 2
Available processors: 2
Available processors: 2
Available processors: 2


[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Factions%2Fruns%2F4119919022=05%7C01%7Cdasmith%40vmware.com%7C7b2cf42318694513e67208db0977c63d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638114182273485483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=unVvHQh5KW2a9ELRAduFXhGS%2B3ahspCpq1NGP9IFAq8%3D=0



On Mon, 23 Jan 2023 at 11:05, Sai Boorlagadda 
wrote:

> After working through unit tests and the builds are passing. I am working
> on adding an integration step to the build pipeline.
>
> Looks like there are a few (4 tests) failing[1] on the integration suite.
> Let me know if anyone interested to look into them. It would really good to
> get integration tests enabled on develop.
>
> Below 4 tests needs to be analyzed and fixed:
> 1) LocatorLauncherJmxSerialFilterPropertyBlankIntegrationTest >
> startDoesNotConfigureJmxSerialFilter_whenPropertyIsBlank_onJava8
> 2) LocatorLauncherGlobalSerialFilterPropertyEmptyIntegrationTest >
> startDoesNotConfigureGlobalSerialFilter_whenPropertyIsEmpty
> 3) VersionCommandJUnitTest > initializationError
> 4) LoadClusterConfigFromDirInt > canStartWithDeployedJarInClusterConfig
>
> 1. 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Factions%2Fruns%2F3983609395%2Fjobs%2F6829148633=05%7C01%7Cdasmith%40vmware.com%7C7b2cf42318694513e67208db0977c63d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638114182273485483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jIvQuxFsYNFyXEyUuuMVHPdrodXymM9IGYaw4lWIZ2k%3D=0
>
> Sai
>

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

Re: priority list

[Dan Smith]

I added you to that group Sai, good luck!

-Dan

From: Sai Boorlagadda 
Sent: Saturday, November 12, 2022 8:11 AM
To: dev@geode.apache.org 
Subject: Re: priority list

!! External Email

Dan,

Could you add me to this ldap group 'hudson-jobadmin' to get administrative
account for Jenkins?

[1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fplugins%2Fservlet%2Fmobile%3FcontentId%3D65147535%23Jenkins-HowdoIgetanaccountdata=05%7C01%7Cdasmith%40vmware.com%7C39d2a3a41511414c985708dac4c89793%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638038663080305552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=L4eRMo0%2BdqW8%2F6nDKzRuzZME846WcGSgpCXsY1SMI9Y%3Dreserved=0
?

Sai

On Sat, Nov 12, 2022, 7:33 AM Sai Boorlagadda 
wrote:

> Thanks, Mario for the context.
>
> I am also reading about GA performance/scalability issues[1] from other
> apache project migration efforts, so it seems Jenkins would be the better
> option for Geode. Let me read about getting started with Jenkins.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FBUILDS%2FGitHub%2BActions%2Bstatusdata=05%7C01%7Cdasmith%40vmware.com%7C39d2a3a41511414c985708dac4c89793%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638038663080305552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=FUBkLgzZ2gDE01NUpkuC4Lymn3Zq5jBp%2BX9KhPaEhbs%3Dreserved=0
>
> On Sat, 12 Nov 2022 at 04:42, Mario Salazar de Torres
>  wrote:
>
>> Hi,
>> About GitHub actions, there are currently some limitations you I pointed
>> out previously in the devlist.
>> Even tho, I was stuck in the process of migrating geode-native CI to GH
>> actions, mostly since I didn't have the necessary permissions.
>> If you want to have further info about GH actions, you can check Apache
>> BUILDS list.
>>
>> And as for Geode repository, considering the number of resources its CI
>> requires, I'd say GH actions is a no go...
>> Also, I think it was Dan Smith, the one that pointed out that Apache has
>> a Jenkins instance available, so every Apache project can use its resources.
>> My guess is that Apache Jenkins infra would be a better fit for Geode
>> repository. Still, it remains to be seen, since resource requirements on
>> that repository are really high.
>>
>> Sorry I couldn't be of more help, but at least I hope these pointers are
>> useful.
>>
>> /Mario
>>
>> 
>> From: Niall Pemberton 
>> Sent: Saturday, November 12, 2022 10:46 AM
>> To: dev@geode.apache.org 
>> Subject: Re: priority list
>>
>> On Sat, Nov 12, 2022 at 3:24 AM Sai Boorlagadda <
>> sai.boorlaga...@gmail.com>
>> wrote:
>>
>> > Hello Devs,
>> >
>> > I would like to understand some of the top priority items that we should
>> > focus and spend our time on while we ramp up with new community members.
>> >
>> > Any pointers to the scope of the next release or a list of items we
>> should
>> > do as part of this transition. While going through the mailing list what
>> > immediately caught my eye is CI/CD migration to Github actions.
>> >
>>
>> I would say the number one priority is getting a CI instance setup. I
>> guess
>> you've seen what Mario said about his efforts on GitHub actions?
>>
>> Niall
>>
>>
>> >
>> > Sai
>> >
>>
>

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

Update: Geode not moving to the attic

[Dan Smith]

Hi folks,

I have some good news! Notifying the board mailing list of our vote to move 
Geode to the attic got some attention. Several inactive PMC members and some 
new folks from the Apache membership have expressed interest in helping with 
the project.

With this help, we do not need to move Geode to the attic. We have withdrawn 
the resolution from the next board meeting.

I and the other remaining VMware contributors will still need scale back our 
involvement, so the PMC is in the process of reorganizing and finding a new 
chair.

For those folks who were following the attic vote and offered support, thank 
you and I'm sorry for the roller coaster ride. I hope this outcome is a welcome 
surprise, and I hope you will consider staying engaged with Geode. This is a 
great opportunity to become actively involved and help the project succeed.

Thanks,
-Dan

[DRAFT] Geode Board Report for November 9th

[Dan Smith]

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.

Re: [RESULT] [VOTE] Move geode to the attic

[Dan Smith]

For the one contributor who offered to help with the project, thanks Rupert!  
However, it didn't seem to me like we had raised enough support at this point 
to continue having a working PMC even with your help. We do appreciate the 
offer.

I think if you are serious about taking over the project, there are options to 
raise a community and reboot the project within the apache foundation, so this 
doesn't have to be the end of the line.

-Dan


From: Dan Smith 
Sent: Thursday, November 3, 2022 3:15 PM
To: u...@geode.apache.org ; dev@geode.apache.org 

Subject: [RESULT] [VOTE] Move geode to the attic 
 
This vote is now closed, thanks to everyone who voted. The vote has passed with 
4 binding PMC members voting to move the project to the attic.

I think the next step is that I will add an item to the agenda for the next 
Apache board meeting for the board to consider. I'll also put the details in 
our board report and share out a draft.

Results:

Binding PMC members
--
+1  - Xiaojian, Anthony, Mark, Dan

Committers and Users
-
+1 - Ernie, Donal, Ali, Ajay
 -1 - Rupert, Pieter

[RESULT] [VOTE] Move geode to the attic

[Dan Smith]

This vote is now closed, thanks to everyone who voted. The vote has passed with 
4 binding PMC members voting to move the project to the attic.

I think the next step is that I will add an item to the agenda for the next 
Apache board meeting for the board to consider. I'll also put the details in 
our board report and share out a draft.

Results:

Binding PMC members
--
+1  - Xiaojian, Anthony, Mark, Dan

Committers and Users
-
+1 - Ernie, Donal, Ali, Ajay
 -1 - Rupert, Pieter

Re: [VOTE] Move geode to the attic

[Dan Smith]

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 
Sent: Sunday, October 30, 2022 10:51 PM
To: u...@geode.apache.org ; 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 
Date: Friday, October 28, 2022 at 3:15 PM
To: u...@geode.apache.org , 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 
Sent: Tuesday, October 25, 2022 12:30 PM
To: u...@geode.apache.org ; 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 
Sent: 25 October 2022 18:38
To: dev@geode.apache.org
Cc: 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%7C638027923164232642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=gxqKYTayLzJG0r%2B4BT2ZfHjkgPN917aElv3qbsfqwoU%3Dreserved=0>


> 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%7Cdasmith%40vmware.com%7C37d98042d8ef49984ade08dabb0402fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638027923164232642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=R1A7eGrb%2B3My4s%2FYoqR3R6Z9J0%2F%2BNrSI11Bv5Q8h5dU%3Dreserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fbx6t1cppbj7nmfjnf9gtcqjljp8bdf0ydata=05%7C01%7Cdasmith%40vmware.com%7C37d98042d8ef49984ade08dabb0402fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638027923164232642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=R1A7eGrb%2B3My4s%2FYoqR3R6Z9J0%2F%2BNrSI11Bv5Q8h5dU%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: [VOTE] Move geode to the attic

[Dan Smith]

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 
Sent: Tuesday, October 25, 2022 12:30 PM
To: u...@geode.apache.org ; 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 
Sent: 25 October 2022 18:38
To: dev@geode.apache.org
Cc: 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%7Cf225bd8095d547424ccb08dab6bf7be7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638023230840068545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=wo6wDQSJk8FdjjJs%2F8IM5Lnh2sn9b%2F8E2Epr3Uw9HlM%3Dreserved=0


> 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%7Cdasmith%40vmware.com%7Cf225bd8095d547424ccb08dab6bf7be7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638023230840068545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=lBa0R9kBOwMiWAt6amSAlzvNmx4eZa%2BWW3namhLMgOg%3Dreserved=0
>
> 
>
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

[VOTE] Move geode to the attic

[Dan Smith]

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://lists.apache.org/thread/bx6t1cppbj7nmfjnf9gtcqjljp8bdf0y

CVE-2022-34870: Apache Geode stored Cross-Site Scripting (XSS) via data injection vulnerability in Pulse web application

[Dan Smith]

Apache Geode versions up to 1.15.0 are vulnerable to a Cross-Site
Scripting (XSS) via data injection when using Pulse web application to
view Region entries.

This issue is being tracked as GEODE-10411

CVE-2022-34870: Apache Geode stored Cross-Site Scripting (XSS) via data injection vulnerability in Pulse web application

[Dan Smith]

Apache Geode versions up to 1.15.0 are vulnerable to a Cross-Site Scripting 
(XSS) via data injection when using Pulse web application to view Region 
entries.

This issue is being tracked as GEODE-10411

[DISCUSS] Move geode to the attic

[Dan Smith]

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://lists.apache.org/thread/d88byb42gm5wplzqwkgywg3w9vtj64dr
[2] https://attic.apache.org/process.html

New committer - Jakov Varenina

[Dan Smith]

The Apache Geode Project Management Committee has invited Jakov Varenina to 
become a Geode committer and we are pleased to announce he has accepted. Please 
join me in welcoming Jakov!

Best regards,
Dan Smith on behalf of the Apache Geode PMC

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

[Dan Smith]

If github actions don't pan out, we previously ran geode CI on the apache 
jenkins instance. According to the instructions I should be able to grant folks 
access if anyone wants to try the jenkins option - 
https://cwiki.apache.org/confluence/display/INFRA/Jenkins

-Dan

From: Mario Salazar de Torres 
Sent: Friday, October 7, 2022 1:57 PM
To: dev@geode.apache.org 
Subject: Re: https://concourse.apachegeode-ci.info/ is shutting down

⚠ External Email

Hi everyone,
Following up on this, I looked into the view of the ASF regarding GitHub 
Actions and as they describe here: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FBUILDS%2FGitHub%2BActions%2Bstatusdata=05%7C01%7Cdasmith%40vmware.com%7C303729bb7daa4c52ed0408daa8a68bcf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007730578843543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2BLJeO6f3%2Fk92Vye%2BYHWRWA2MyCezbRsM6UoEHrojOh8%3Dreserved=0
 among lots of places in the bu...@apache.org list, there are mainly 2 issues:

  *Per-Enterprise limitations. Currently GitHub is giving for free an 
Enterprise status for the Apache organization. And the thing is GitHub 
establishes a concurrent job limit per Enterprise, in this case 180 jobs, as 
can be seen here: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.github.com%2Fen%2Factions%2Flearn-github-actions%2Fusage-limits-billing-and-administration%23usage-limitsdata=05%7C01%7Cdasmith%40vmware.com%7C303729bb7daa4c52ed0408daa8a68bcf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007730578843543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=glfd3pwp6afDPSbTRVzIuTkWH3MPYRIUsfAUR1SuJBM%3Dreserved=0.
Also, you can see there is a disclaimer stating that this limit might be 
increased on demand, which TBH is something I don't know yet if happened.
On the other side, apparently there is a quota for the amount of time executing 
GitHub Actions per month and organization (ref: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F6lbqr0f6mqt9s8ggollp5kj2nv7rlo9sdata=05%7C01%7Cdasmith%40vmware.com%7C303729bb7daa4c52ed0408daa8a68bcf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007730578843543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=wkXtuIAX6Y7fjENG875VnHRfPqzBj2kLFowxK1Jd6Fc%3Dreserved=0)
 so this is another downside.
As an alternative, ASF is/has been in conversations with GitHub so 
per-repository quotas/tracking is set into place, but it seems this is not 
happening any time soon, as this will surely help ASF to keep assign credits to 
each project using GHA.

  *   Security concerns. There are several concerning security concerns to 
which ASF propose several mitigations, which will require to change the way I 
wanted to approach the pipelines. Still, this part can be solved, and also, the 
biggest security concerns are related to self-hosted runners, but that's not 
going to be the case due to the lack of sponsors and also, btw, ASF is only 
approving the use of them for an specific set of projects and only under ASF's 
support and supervision.
[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.githubassets.com%2Fimages%2Fmodules%2Fopen_graph%2Fgithub-logo.pngdata=05%7C01%7Cdasmith%40vmware.com%7C303729bb7daa4c52ed0408daa8a68bcf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007730578843543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ODE79SLkU2tSmqxauJnG3MJ%2BRgx%2B5wueYmD3%2FJKXCVk%3Dreserved=0]
Usage limits, billing, and administration - GitHub 
Docs
Job matrix - A job matrix can generate a maximum of 256 jobs per workflow run. 
This limit applies to both GitHub-hosted and self-hosted runners. Workflow run 
queue - No more 

Re: [VOTE] Apache Geode 1.15.1.RC1

[Dan Smith]

+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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=7zMStKFFe%2BRMN9wC9mc9CzcCTp%2FQ380XEC%2BhxpRKUFc%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=qqDFhYcCLDp6Q8kg%2BhbNaWhOgYGfF5yeAB5IPDK0ozU%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1139data=05%7C01%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=NqiM2xETJDovY%2BqwoN1gLim%2FzK%2FMNwqRrKmuFL93WGw%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ir1W1d07Oiun%2BybEjZTRiP9FbzfKxIHSvaa13MQNNz4%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WkQLjvfYevqJjKqdUePxnD%2BH3wxxSoES0PHOv3caUY0%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=zSQlSX1GUMpufXoExF55%2FtMV9iwQgVkdbLG5u9n4f%2Bo%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MiIBrjftHnxUIYuJqK6WeBffJLVQnYGkYimuYcjMO4o%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=m4f0uwORaYdlAbpHlgiBgw8PHVj7WeujLUs3sOreToQ%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%7Cdasmith%40vmware.com%7C9558a94d0d054d885a2608daa2173f88%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638000518045849350%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=C0R4wI4gE7lkAonYlnmFeoIGacbXQfzcfx4ivofl%2Fzs%3Dreserved=0

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

Re: Jira Contributors vs Committers vs "Assign User"

[Dan Smith]

I also think this is a great idea if we can do it. Thanks for bringing it up, 
Kirk!

-Dan

From: Mark Bretl 
Sent: Thursday, September 22, 2022 10:35 AM
To: dev@geode.apache.org 
Subject: Re: Jira Contributors vs Committers vs "Assign User"

⚠ External Email

Hey Kirk,

I think this is a great idea. I do not see any reason why Contributors
should not be able to assign issues to themselves, it would definitely help
onboarding new contributors to the project without giving more permissions
as necessary. No need to contact Infra for this change, I have Jira Admin
permissions and can do the task.  I will work on this probably tomorrow.

--Mark

On Wed, Sep 21, 2022 at 2:08 PM Kirk Lund  wrote:

> Contributors have the "Assignable" permission, but are lacking "Assign
> User" which despite the text description means that they cannot assign a
> ticket to themselves. Basically Contributors cannot assign anything to
> anyone.
>
> Ideally, we want to add "Assign User" to Contributors rather than keep
> adding everyone who comes along to the Committers group.
>
> The Apache Geode PMC and admins do not have the necessary permissions to
> edit the Roles. We can only add, assign and remove Users. If we want to
> edit Contributors to add "Assign User" we'll need to have one of us contact
> ASF Infra to request this change to our Project in Jira.
>
> Otherwise we have to assign all newcomers to the Committers group instead
> of Contributors.
>
> Note: I haven't changed any Users or Roles in Jira (I just have time to
> quickly post this message right now).
>
> -Kirk
>



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

Re: Request JIRA Ticket Assgin Permission

[Dan Smith]

Hi Xu Weijie,

I gave you permission in JIRA, you should be able to assign that issue to 
yourself now.

If you haven't already seen it, here is our wiki page with some helpful 
information about how to contribute - 
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute.

Thank you!
-Dan



From: Weijie Xu M 
Sent: Monday, August 29, 2022 3:33 AM
To: dev@geode.apache.org 
Subject: Request JIRA Ticket Assgin Permission

⚠ External Email

Hi community,

  I'm newcomer for geode contribution, and I want assign ticket [GEODE-10409] 
Rebalance Model Missing Collocated Regions At Server Startup - ASF JIRA 
(apache.org)
 to myself.
  Could you help give me assign permission for JIRA tickets? Thanks.

BRs/Xu Weijie



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

Re: [DRAFT] Apache Geode Board report due by Wed May 11th

[Dan Smith]

I submitted this report to the board.

Thanks!
-Dan

From: Dan Smith 
Sent: Monday, May 9, 2022 4:20 PM
To: dev@geode.apache.org 
Subject: [DRAFT] Apache Geode Board report due by Wed May 11th

Here is a draft of our board report for this quarter. Please let me know by the 
end of the day Tuesday if there is anything you would like me to change or add.

Thanks!
-Dan

## 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 (7 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:
The project has issued several patch releases since the last report to fix
stability issues such as a socket leak:
- 1.14.4: 2022-03-18
- 1.13.8: 2022-03-15
- 1.12.9: 2022-03-10

The project has started the stabilization phase of the next minor release,
1.15.0. We previously cut a release branch, reverted to develop, and are back
to stabilizing the release branch again. Some notable features include JDK 17
support, removing ACE from the C++ client, and expiring and re-authenticating
clients with new credentials.

## Community Health:
The project membership hasn't changed much in a last year.

The community is fairly active with several new RFCs, a number of mailing list
discussions, and a couple more live video discussions with community members
in this last quarter.

[DRAFT] Apache Geode Board report due by Wed May 11th

[Dan Smith]

Here is a draft of our board report for this quarter. Please let me know by the 
end of the day Tuesday if there is anything you would like me to change or add.

Thanks!
-Dan

## 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 (7 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:
The project has issued several patch releases since the last report to fix
stability issues such as a socket leak:
- 1.14.4: 2022-03-18
- 1.13.8: 2022-03-15
- 1.12.9: 2022-03-10

The project has started the stabilization phase of the next minor release,
1.15.0. We previously cut a release branch, reverted to develop, and are back
to stabilizing the release branch again. Some notable features include JDK 17
support, removing ACE from the C++ client, and expiring and re-authenticating
clients with new credentials.

## Community Health:
The project membership hasn't changed much in a last year.

The community is fairly active with several new RFCs, a number of mailing list
discussions, and a couple more live video discussions with community members
in this last quarter.

Re: [discuss] Future of the geode-redis module

[Dan Smith]

The PRs to remove this module have been approved merged - from geode, 
geode-benchmarks, and geode-examples.

-Dan

From: Dan Smith 
Sent: Wednesday, May 4, 2022 2:06 PM
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module

Since it seems there is consensus to remove this module, I created this PR - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7657data=05%7C01%7Cdasmith%40vmware.com%7C14930b4554a64bb27a5f08da2e12028a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872952170457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=l0rohEOfWZASMGmsiq8NCvB%2F1aIN3NbAM45aQdcHS6k%3Dreserved=0.
 If folks approve of this PR there will be additional PRs to geode-benchmarks 
and geode-examples to remove references to this module.

-Dan


From: Alexander Murmann 
Sent: Wednesday, May 4, 2022 11:04 AM
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module

Hi Donal,

I think Dan, Ray or Jens were going to issue a PR in the next few days that 
would remove the experimental Redis functionality. Given this is not a complex 
architectural change that might warrant deeper discussion, I would expect that 
the voting inherent to the PR would suffice. Especially, given that the 
discussion here seemed very non-controversial.

From: Donal Evans 
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module

It's been almost a month since this discussion was started, and all the 
responses have been supportive of the idea. Is this still something that the 
Geode community intends to do? Should there be a [vote] email sent out to 
confirm this course of action?

From: Alexander Murmann 
Sent: Thursday, April 14, 2022 5:15 PM
To: geode 
Subject: [discuss] Future of the geode-redis module

Hi Geode community!

A while ago engineers from VMware started to improve the geode-redis module 
that has been in Geode for several years, but never had been completed. This 
involved adding more tests for existing functionality, as well as adding 
support for more commands.

VMware will not continue this investment in the geode-redis module. While the 
geode-redis module is in a much better place than two years ago there still is 
a lot of work left to make it a viable option for most of our users and the 
module is still in an experimental state.

For the community this poses the question of what we want to do with the 
existing code. This work now has been started and stopped twice. All code comes 
with a maintenance burden which adds 
up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2Fdata=05%7C01%7Cdasmith%40vmware.com%7C14930b4554a64bb27a5f08da2e12028a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872952170457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Muoq%2FVBILzuQVebwnbjhuHW3TGXwQAXBoylBzm0UfCA%3Dreserved=0>.
 Dependencies might need to be updated; flaky tests fixed and it brings 
cognitive overhead for us and our users. Unless someone else in the community 
steps up to take on the task of maintaining the geode-redis module, I propose 
to remove the code from our develop branch and give everyone more bandwidth to 
use elsewhere.

Thank you all in advance for your thoughts

Re: [discuss] Future of the geode-redis module

[Dan Smith]

Since it seems there is consensus to remove this module, I created this PR - 
https://github.com/apache/geode/pull/7657. If folks approve of this PR there 
will be additional PRs to geode-benchmarks and geode-examples to remove 
references to this module.

-Dan


From: Alexander Murmann 
Sent: Wednesday, May 4, 2022 11:04 AM
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module

Hi Donal,

I think Dan, Ray or Jens were going to issue a PR in the next few days that 
would remove the experimental Redis functionality. Given this is not a complex 
architectural change that might warrant deeper discussion, I would expect that 
the voting inherent to the PR would suffice. Especially, given that the 
discussion here seemed very non-controversial.

From: Donal Evans 
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org 
Subject: Re: [discuss] Future of the geode-redis module

It's been almost a month since this discussion was started, and all the 
responses have been supportive of the idea. Is this still something that the 
Geode community intends to do? Should there be a [vote] email sent out to 
confirm this course of action?

From: Alexander Murmann 
Sent: Thursday, April 14, 2022 5:15 PM
To: geode 
Subject: [discuss] Future of the geode-redis module

Hi Geode community!

A while ago engineers from VMware started to improve the geode-redis module 
that has been in Geode for several years, but never had been completed. This 
involved adding more tests for existing functionality, as well as adding 
support for more commands.

VMware will not continue this investment in the geode-redis module. While the 
geode-redis module is in a much better place than two years ago there still is 
a lot of work left to make it a viable option for most of our users and the 
module is still in an experimental state.

For the community this poses the question of what we want to do with the 
existing code. This work now has been started and stopped twice. All code comes 
with a maintenance burden which adds 
up.
 Dependencies might need to be updated; flaky tests fixed and it brings 
cognitive overhead for us and our users. Unless someone else in the community 
steps up to take on the task of maintaining the geode-redis module, I propose 
to remove the code from our develop branch and give everyone more bandwidth to 
use elsewhere.

Thank you all in advance for your thoughts

Re: Peer-to-peer connections use the --server-port causing the server to hang during startup

[Dan Smith]

I think the membership-port-range determines the port that the server side of 
the TCP socket is listening on.

What I see in your log statement is the port number of the client side of the 
socket (where it says localport=37392). The port for the client side of a 
socket comes from the ephemeral port range configured on your OS - usually 
32768–60999 in linux.

https://en.wikipedia.org/wiki/Ephemeral_port

-Dan

From: Jakov Varenina 
Sent: Monday, May 2, 2022 5:49 AM
To: dev@geode.apache.org 
Subject: Peer-to-peer connections use the --server-port causing the server to 
hang during startup

⚠ External Email

Hi devs,


We have noticed that some peer-to-peer connections use ports outside the
range defined by the membership-port-range (41000-61000) parameter:


[vm1] membership-port-range=41000-61000

[vm1] [debug 2022/05/02 11:15:57.968 CEST server-1  tid=0x1a] starting peer-to-peer handshake on
socket Socket[addr=/192.168.1.36,port=49913,*localport=37392*]


Is it expected that peer-to-peer connections use ports outside the above
range?


Also, due to the above behavior, the following bug occurs:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10268data=05%7C01%7Cdasmith%40vmware.com%7Cf61b0d0e14774737c7ee08da2c3a2e72%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637870925648179770%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=VJQGl83OSKWTWwn%2FR7bdJorcQqAP3goEPz4cddHHgZM%3Dreserved=0



Best Regards,

Jakov



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

Re: Geode Jira permissions

[Dan Smith]

Hi Oleksii,

Welcome! You should have access to the Geode JIRA now. If you haven't already 
you might want to check out our How to 
Contribute 
page for information on how to get started contributing to Geode.

Thanks,
-Dan

From: SITNIANSKYI Oleksii 
Sent: Wednesday, April 6, 2022 1:45 AM
To: dev@geode.apache.org 
Subject: Geode Jira permissions

⚠ External Email

Hello All,

Could you please provide me permissions to be assigned JIRA tickets on the 
Geode project.

My JIRA credentials:
Username: zsitole
Email: zsit...@ericsson.com

Thank you.
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.



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

Re: Request access to JIRA

[Dan Smith]

Hi Michael,

Welcome! You should have access now. If you haven't already, you might want to 
check out our How to 
Contribute 
page for information on how to get started contributing to Geode.

Thanks,
-Dan

From: ALBUL Michael 
Sent: Wednesday, April 6, 2022 2:33 AM
To: dev@geode.apache.org 
Subject: Request access to JIRA

⚠ External Email

Hi all,

Can you give me access to JIRA so I can assign tickets?
My JIRA username is `zalmbic`

Thanks,
Michael.
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.




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

Re: Request for Permissions

[Dan Smith]

Hi Max,

Welcome! I gave you permissions to assign tickets to yourself on the geode 
JIRA. For submitting changes to the geode and geode-site repositories, please 
go ahead and file pull requests against those repos on github. You can check 
out our How to 
Contribute 
page for more information on how to get started.

Thanks!
-Dan

From: Max Hufnagel 
Sent: Tuesday, April 5, 2022 3:31 PM
To: dev@geode.apache.org 
Subject: Request for Permissions

⚠ External Email

Hi All,

I would like permissions to be assigned JIRA tickets on the Geode project
and to push to the geode repository and the geode-site repository.

Thank you,
Max Hufnagel



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

Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

[Dan Smith]

+1

Ran smoketest_rc.sh

-Dan

From: Eric Shu 
Sent: Tuesday, March 15, 2022 5:01 PM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

+1

Run end to end test cases against the build without seeing new issues.

From: Donal Evans 
Sent: Tuesday, March 15, 2022 4:25 PM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

+1

Confirmed that performance across a variety of workloads is on par with 
previous releases.

From: Dick Cavender 
Sent: Tuesday, March 15, 2022 3:41 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.4.RC1

Hello Geode Dev Community,

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

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

Voting deadline:
3PM PST Fri, March 18 2022

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.4data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Wnl3egRmvIsJqBEkzuqU9VNnjpeCPW34oIrxOPCV47U%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.4.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=PJlhXtl9kdDSnacv1Uy%2BJHQssKXloX%2FQLhWpDmWZLQs%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1137data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eVwkf1B9oKtq4MAnjNio0Le9oBf8GzHVisXLos%2BjyAU%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=gcQa%2FsRJZIsdHiJHLzfY5XgtkxUqgJC9ffnYdL2tzj4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=sTmANacnskx5hcuqERsyS7W95Q2PHU1rI2jMRz4ASqI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xG5hvbe2hOSNnBnM%2FJf3Xhh2DnBBAVZY39JESt%2FEHr4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=55zB3B7e8N0fKDXqX1JNB8aU5d4%2FGt3ENfZCBvZkrxU%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdasmith%40vmware.com%7Cb2c7b145a1f443dbcc8708da06e01d23%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829856898429361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=59XUNNB1uPqbDMQrh%2BKyT1j%2Bd%2FAOkcJ3bDOI5RSriP8%3Dreserved=0

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1

[Dan Smith]

+1 - ran smoketest_rc.sh

-Dan

From: Nabarun Nag 
Sent: Tuesday, March 15, 2022 9:55 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1

+1 based on pipeline status of the artifacts

Regards
Naba


From: Dick Cavender 
Sent: Wednesday, March 9, 2022 3:47 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.8.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.8.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, March 15 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.8data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=47OjBeu4yzFVgK6I1Smk5NeIs97dG5bybA8tE0W7ORc%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.8.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kCXPgCixoO3wRqiEV%2F5HKqHv5vmt5E97qqXXzCe2%2F9M%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1135data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=YAUI0Za8hd%2B2HunM%2BdFFKChO%2FVmUzpQH%2BUKI2ZNnKQ0%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3WV2MqX%2FVO%2BJ9cCMdqMP5A9Fk7W9lwCZ1%2B9eJqPNrQM%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qgdONhR0mmFc90mcVL2HnpV6V7gfOhPfs9IS9HkKXVs%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3nlS7P1GQw1kriclCFRdKYgSSIrq3sROsxIrzH8TOoQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.8.RC1data=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=K%2Bs9pLgX9FWpEnsOrRyj7FoGZ3b%2FSfcww4EtvUDtaVE%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=50WUs9ZoO4Yh%2Bsvieh2c76i2SiKlWZ8ZcF7FdCKPtiE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Cdasmith%40vmware.com%7C609eab530f4a4bb8e4c608da06a4a3c4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637829601447708868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=clm0XkZYwGKoUwhN3eg2j3IkojMjSOI0a2%2FVufoN5L4%3Dreserved=0

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

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1

[Dan Smith]

+1


  *   Ran smoketest_rc - 
https://github.com/apache/geode/tree/develop/dev-tools/release-testing
  *   verified concourse build passed
  *   looked at artifacts



From: Donal Evans 
Sent: Wednesday, March 9, 2022 9:04 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1

+1

Confirmed that performance is on par with previous releases for a variety of 
workloads

From: Dick Cavender 
Sent: Friday, March 4, 2022 2:05 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.9.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.9.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 Wed, March 9 2022.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.9data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0monUNkMQZqfVmpXKenmzA%2FUVqvU8kyTXXhT8Np%2B8ks%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.9.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KkuUpKBZCUFqFBARZfpPRQpmjtXeBViamrXRnwJ16KE%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1131data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Aj6poeSKodYfIUsOXr8WfpwZP2dPpnk%2FwXJnzAx3rmw%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VN1dbUf4jwKAgHLauuLf0dd0KJct5yT3tMHeVixcCQc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mwQbdBPM4BZppjAyAbMCk%2FzCgtnbnQaDNW9KX%2FrRpz4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Fsjno%2Br8iszz70EQaF%2BTMQg%2BjrWXhV6W3uHLY8JYwK0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.9.RC1data=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vayn8jXJs%2FWIu6uAas0zRa%2B4H47PEf6dJpt6%2BRwYItw%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rf9kmVC44tdj7hiHQoEAgyEa%2FLYjyKAG9s56mSGVQFs%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cdasmith%40vmware.com%7C02d6b3c60ef34765792008da01eef143%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637824423009178842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=LDSpKlqObfHs1s%2FiYSQoxmV%2B6hHo6N7%2FFo0vDgUuVE4%3Dreserved=0

Geode's KEYS file 

Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

[Dan Smith]

Sounds good. BTW, I don't mean to discount all the hard work folks did getting 
these patches out quickly. Thanks again for everyone who helped with that 
effort!

-Dan

From: Owen Nichols 
Sent: Friday, February 4, 2022 2:52 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

That's a much better way to put it, Mark.  Thanks!

On 2/4/22, 2:50 PM, "Mark Bretl"  wrote:

I agree with Dan here that bragging about 'one of the quickest' is not
needed, but noting we are up-to-date with Log4J patches and have
documentation for mitigation might be a better approach.

My $.02

--Mark

On Fri, Feb 4, 2022 at 11:34 AM Dan Smith  wrote:

> Counting the kafka connector I'm not sure bragging about CVE patching
> speed is justified, but otherwise looks good to me!
>
> -Dan
> 
> From: Nabarun Nag 
> Sent: Tuesday, February 1, 2022 2:25 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> Thank you for the feedback, please find the new draft with the added
> review comments.
>
> ## Project Activity:
> We issued 9 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. The project had one of the
> quickest turnaround times from the Log4j2 CVE disclosure to the patch
> releases with the fix. Apache Geode Kafka Connector 1.1.0 was also 
released
> this quarter.
> We have also started the effort to remove the use of deprecated components
> in the project.
>
> > Recent Releases of Apache Geode:
> > - 1.14.3 was released on 2022-01-25
> > - 1.13.7 was released on 2022-01-22
> > - 1.12.8 was released on 2022-01-13
> > - 1.12.7 was released on 2022-12-17
> > - 1.13.6 was released on 2021-12-17
> > - 1.14.2 was released on 2021-12-17
> > - 1.12.6 was released on 2021-12-11
> > - 1.13.5 was released on 2021-12-11
> > - 1.14.1 was released on 2021-12-11
>
>
> 
> From: Owen Nichols 
> Sent: Tuesday, February 1, 2022 12:39 PM
> To: dev@geode.apache.org 
> Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
>
> 1.12.8 seems to be missing from the list of releases. Also consider
> bragging about Geode’s turnaround time from CvE disclosure to patch
> release…only one other ASF project got theirs out faster than we did.
>
>
> ---
> Sent from Workspace ONE Boxer<
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxerdata=04%7C01%7Cdasmith%40vmware.com%7C8711fa42cf134533e5f508d9e830fce0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637796119396671277%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5la0l1lFE8X7YzoAAIDoOr4X4Z6tT0IcLZj89d4F%2F14%3Dreserved=0
> >
>
> On January 31, 2022 at 1:57:18 PM PST, Dave Barnes 
> wrote:
> LGTM +1
>
> On Mon, Jan 31, 2022 at 12:50 PM Nabarun Nag  wrote:
>
> > This is a draft of our report to the board. Please let me know if there
> > are details you'd like me to add!
> >
> > --Naba
> >
> > ## 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 Board-level issues at this time.
> >
> > ## Membership Data:
> > Apache Geode was founded 2016-11-15 (5 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:
> > We issued 8 releases this quarter which include an updated Log4j2 
version
> > to handle the remote code execution CVE. Apache Geode Kafka Connector
> 1.1.0
> > was also released this quarter.
> > We have also started the effort to remove the use of deprecated
> components
> > in
> > the project.
> >
> > Recent Releases of 

[DISCUSS] Testing and voting on release candidates

[Dan Smith]

Hi all,

I'd like to suggest something that might make voting on releases a little 
clearer and easier. I feel like we've been a bit vague about what kind of 
testing PMC members are supposed to do on a release candidate, and I see 
different folks (including myself) running different kinds of ad hoc testing.

I'd like to suggest that we should mostly focus on things that are either 
apache requirements for voting on releases or can't reasonably be testing in CI.

The apache release policy [1] says

"Before voting +1 PMC members are required to download the signed source code 
package, compile it as provided, and test the resulting executable on their own 
platform, along with also verifying that the package meets the requirements of 
the ASF policy on releases."

I checked in a script that can do the building and signature verification for 
you [2]. My hope is that we can improve this script do to all of the testing 
that we think is important to do on a developers machine before VOTING +1, and 
free up more time to look at the commits, source files etc. and thinking about 
if this is what we should be releasing.

I'm not trying to discourage any ad hoc testing someone feels like they want to 
do, but I do want to make sure that everyone is in agreement on what we should 
be doing before voting on a release and hopefully make it so that everyone 
feels comfortable voting without wondering what they are supposed to test.

[1] https://www.apache.org/legal/release-policy.html#approving-a-release
[2] https://github.com/apache/geode/tree/develop/dev-tools/release-testing

Thanks,
-Dan

Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

[Dan Smith]

Counting the kafka connector I'm not sure bragging about CVE patching speed is 
justified, but otherwise looks good to me!

-Dan

From: Nabarun Nag 
Sent: Tuesday, February 1, 2022 2:25 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

Thank you for the feedback, please find the new draft with the added review 
comments.

## Project Activity:
We issued 9 releases this quarter which include an updated Log4j2 version
to handle the remote code execution CVE. The project had one of the quickest 
turnaround times from the Log4j2 CVE disclosure to the patch releases with the 
fix. Apache Geode Kafka Connector 1.1.0 was also released this quarter.
We have also started the effort to remove the use of deprecated components in 
the project.

> Recent Releases of Apache Geode:
> - 1.14.3 was released on 2022-01-25
> - 1.13.7 was released on 2022-01-22
> - 1.12.8 was released on 2022-01-13
> - 1.12.7 was released on 2022-12-17
> - 1.13.6 was released on 2021-12-17
> - 1.14.2 was released on 2021-12-17
> - 1.12.6 was released on 2021-12-11
> - 1.13.5 was released on 2021-12-11
> - 1.14.1 was released on 2021-12-11



From: Owen Nichols 
Sent: Tuesday, February 1, 2022 12:39 PM
To: dev@geode.apache.org 
Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th

1.12.8 seems to be missing from the list of releases. Also consider bragging 
about Geode’s turnaround time from CvE disclosure to patch release…only one 
other ASF project got theirs out faster than we did.


---
Sent from Workspace ONE 
Boxer

On January 31, 2022 at 1:57:18 PM PST, Dave Barnes  wrote:
LGTM +1

On Mon, Jan 31, 2022 at 12:50 PM Nabarun Nag  wrote:

> This is a draft of our report to the board. Please let me know if there
> are details you'd like me to add!
>
> --Naba
>
> ## 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 Board-level issues at this time.
>
> ## Membership Data:
> Apache Geode was founded 2016-11-15 (5 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:
> We issued 8 releases this quarter which include an updated Log4j2 version
> to handle the remote code execution CVE. Apache Geode Kafka Connector 1.1.0
> was also released this quarter.
> We have also started the effort to remove the use of deprecated components
> in
> the project.
>
> Recent Releases of Apache Geode:
> - 1.14.3 was released on 2022-01-25
> - 1.13.7 was released on 2022-01-22
> - 1.12.7 was released on 2022-12-17
> - 1.13.6 was released on 2021-12-17
> - 1.14.2 was released on 2021-12-17
> - 1.12.6 was released on 2021-12-11
> - 1.13.5 was released on 2021-12-11
> - 1.14.1 was released on 2021-12-11
>
> Work on releasing 1.15.0 is progressing as planned.
>
> Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18.
>
> ## Community Health:
> - Continuing our monthly video conferences.
> - Addition of Kafka Connector project to grow the community.
> - Mailing lists are seeing the usual amount of traffic involving
> discussions
> related to improving performance, operation protocols, etc.
>
>
>

Re: Changes to Public API Return Only Interfaces

[Dan Smith]

> When a public API interfaces has no use case where 3rd parties would 
> implement, such as return types or factory allocated implementations, there 
> should not be a compile time breaking change. In the case of IndexStatistics 
> there is no use case where a 3rd party could implement and provide their 
> instance to Geode.

In the past we have added methods to these sorts of interfaces and not 
considered it a breaking change. I think this came up again recently in the 
context of adding new methods to the GatewaySenderFactory.  I think it make 
sense to continue that practice - in many cases there is no reasonable default 
method implementation. Since Geode is not calling these methods, the user will 
not experience any runtime errors even if they did implement these interfaces 
and compile against an old version of Geode.

In this case, I wonder if IndexStatistics even needs long versions of those 
metrics? Yes, the underlying Statistics class uses long, but perhaps these 
stats can't ever exceed MAX_INT anyway? Anyway, I'm also ok with just adding 
long versions if that's what we think makes sense.

-Dan

From: Jacob Barrett 
Sent: Wednesday, January 19, 2022 9:02 AM
To: dev@geode.apache.org 
Subject: Changes to Public API Return Only Interfaces

Devs,

First off, this is a very forward looking discussion around something that will 
affect upcoming major releases when deprecating public APIs. One of the issues 
I am finding when investigating a few deprecated APIs for removal is that the 
deprecation hasn’t cascaded through to all the dependent APIs. In one specific 
cast, public API o.a.g.cache.query.IndexStatistics has int sized stats despite 
all int sized stats having been deprecated publicly for some time. Removing 
deprecated Statistics API results in a need to deprecate and add new methods to 
IndexStatistics. This is fine and easy enough to do now but it raises a 
question about API compatibility since adding methods to an interface is 
technically a compile time, or source, breaking change.

Adding a method to a public API interface results in a compile failure where 
3rd parties implement that interface. Java solved this by adding the default 
implementation concept. In this specific cast we could add default 
implementations to this IndexStatistics interface but I think there is an 
argument for not.

When a public API interfaces has no use case where 3rd parties would implement, 
such as return types or factory allocated implementations, there should not be 
a compile time breaking change. In the case of IndexStatistics there is no use 
case where a 3rd party could implement and provide their instance to Geode.

Do we want to just blanket add default method implementations to all public API 
interfaces changes or allow the exclusion of this changes when validating API 
changes?

This example can see in PR 7279:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7279%2Ffiles%23diff-e9f3ff077afba249e36bd8eb30c3d6e2a80110c098a00e26711e2a2995751626R68data=04%7C01%7Cdasmith%40vmware.com%7C61856af5d72048bcb0fa08d9db6d79fb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637782085511571890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=bIqlF5G1%2BCbv4WA5pEH91bMT8A3Z8nNiAOOggqd1DBE%3Dreserved=0

You will notice that the CI failed the API check with the following errors:
Error   Class org.apache.geode.cache.query.IndexStatistics: Is not source 
compatible
Error   Method 
org.apache.geode.cache.query.IndexStatistics.getNumberOfBucketIndexesLong(): Is 
not source compatible
• Method added to interface
Error   Method 
org.apache.geode.cache.query.IndexStatistics.getReadLockCountLong(): Is not 
source compatible
• Method added to interface

I would love your thoughts.

-Jake

[ANNOUNCE] Apache Geode Kafka Connector 1.1.0

[Dan Smith]

The Apache Geode community is pleased to announce the availability of
Apache Geode Kafka Connector 1.1.0.

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

The Apache Geode Kafka connector can be used to move data from Apache
Kafka to Apache Geode and vice versa.

This version of the Kafka connector upgrades log4j to version 2.16.0.

The release artifacts can be downloaded from
https://geode.apache.org/releases/

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

Regards,
Dan Smith on behalf of the Apache Geode team

[ANNOUNCE] Apache Geode Kafka Connector 1.1.0

[Dan Smith]

The Apache Geode community is pleased to announce the availability of
Apache Geode Kafka Connector 1.1.0.

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

The Apache Geode Kafka connector can be used to move data from Apache
Kafka to Apache Geode and vice versa.

This version of the Kafka connector upgrades log4j to version 2.16.0.

The release artifacts can be downloaded from
https://www.apache.org/dyn/closer.lua/geode/kafka-connector-1.1.0

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

Regards,
Dan Smith on behalf of the Apache Geode team

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

[Dan Smith]

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

Voting status
==
+1: 3 binding votes
* Nabarun Nag (PMC member)
* Donal Evans (PMC member)
* Jason Huynh (PMC member)

+0: one vote
 * Owen Nichols (Committer)

-0: zero votes

-1: zero votes

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

Thanks!
-Dan


From: Donal Evans 
Sent: Thursday, January 13, 2022 10:18 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

+1 on releasing this

From: Nabarun Nag 
Sent: Tuesday, January 11, 2022 4:45 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

+1 to move along with this release.

Here is the URI of the component archive specification set by Confluent[1]. Our 
first delivery had to be changed to meet these requirements.

Regards
Naba


[1]https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.confluent.io%2Fhome%2Fconnect%2Fconfluent-hub%2Fcomponent-archive.htmldata=04%7C01%7Cdasmith%40vmware.com%7C67bc29ac823b49a4733408d9d6c115b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637776947052247021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BpkOe5bQQInlr9yMtrrWI9rhBR9RUkg7YHdZVjiLn%2Fw%3Dreserved=0

From: Jason Huynh 
Sent: Tuesday, January 11, 2022 9:35 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

+1 for this release

On 1/6/22, 9:22 AM, "Dan Smith"  wrote:

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 
1.12.8 picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier
Agreed, I think we'll want to do another release later to pickup the latest 
geode and log4j. The lack of RC1 is intentional - this is creating an official 
release based on what was already linked from the confluent hub.

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 
and don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.
​Good catch! I created GEODE-9925 for the missing dependencies.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

Can you clarify which things are in conflict? I think the file name for 
geode is not a hard requirement, just a convention we picked. Also the location 
of LICENSE and NOTICE files - is there some confluent requirement? Apache says 
those files should be at the top level for a source distribution, but I'm not 
clear about a binary distribution. For example, our jar files put them under 
META-INF, which I think is the java convention.

My inclination is to continue with this release as is and create a follow 
up release that updates log4j and the LICENSE, NOTICE files, so I'm leaving 
this VOTE open in hopes of getting some more votes.

-Dan

From: Nabarun Nag 
Sent: Tuesday, January 4, 2022 5:13 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

As it is primarily created for Confluent Marketplace we need to follow the 
steps required for hosting in the marketplace, which included how things are to 
be named, folder structure etc.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

We can definitely add the missing licenses and wait for 1.12.8 release of 
Apache Geode to update those dependencies.


Regards
Naba

___

Re: Please add me to the geode community

[Dan Smith]

Hi Nianesh,

You should be able to join this mailing list by sending an email to 
dev-subscr...@geode.apache.org. You may also want to subscribe to the user 
mailing list - user-subscr...@geode.apache.org.

Thanks!
-Dan

From: Nainesh Jhaveri 
Sent: Thursday, January 13, 2022 9:36 AM
To: dev@geode.apache.org 
Subject: Please add me to the geode community

My email ID: is njhav...@vmware.com

I thought I did this earlier, but not sure why I have not seen any voting 
emails.
Thanks,

Sent from 
Mail
 for Windows

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

[Dan Smith]

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 1.12.8 
picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier
Agreed, I think we'll want to do another release later to pickup the latest 
geode and log4j. The lack of RC1 is intentional - this is creating an official 
release based on what was already linked from the confluent hub.

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 and 
don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.
​Good catch! I created GEODE-9925 for the missing dependencies.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

Can you clarify which things are in conflict? I think the file name for geode 
is not a hard requirement, just a convention we picked. Also the location of 
LICENSE and NOTICE files - is there some confluent requirement? Apache says 
those files should be at the top level for a source distribution, but I'm not 
clear about a binary distribution. For example, our jar files put them under 
META-INF, which I think is the java convention.

My inclination is to continue with this release as is and create a follow up 
release that updates log4j and the LICENSE, NOTICE files, so I'm leaving this 
VOTE open in hopes of getting some more votes.

-Dan

From: Nabarun Nag 
Sent: Tuesday, January 4, 2022 5:13 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

As it is primarily created for Confluent Marketplace we need to follow the 
steps required for hosting in the marketplace, which included how things are to 
be named, folder structure etc.

Looking at the list of things to do and conflicts with Geode / Confluent 
requirements. We can remove it from the Apache domain and move it to internal 
open source repo like gpdb or rabbitMQ while keeping the Apache License. 
Alternatives can be the VMware or VMware-labs opensource orgs in Github.

We can definitely add the missing licenses and wait for 1.12.8 release of 
Apache Geode to update those dependencies.


Regards
Naba


From: Owen Nichols 
Sent: Tuesday, January 4, 2022 4:45 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

Quibbles:
- artifact naming does not follow standard naming convention of 
THING-VERSION.tgz and THING-VERSION-src.tgz (also Geode decided to stop 
distributing .zip files years ago)
- not based on the latest Geode 1.12 patch.  I would like to see Geode 1.12.8 
picked up once it's available later this month.
- the log4j version 2.16.0 advertised in this release fixes only 2 of the 4 
recent log4j vulnerabilities.  I would prefer to see log4j 2.17.1.
- vote email is missing a link to release notes and a link to the KEYS file 
used to sign the release.
- artifact paths and email subject are missing "RC1" qualifier

Concerns:
- NOTICE and LICENSE are found inside a "doc" folder instead of at the top 
level of the artifact
- Some dependencies are missing from LICENSE.  While most deps are Apache2 and 
don't require a mention, LatencyUtils is BSD-2 and should be mentioned, and 
likely a few others from Geode's LICENSE need to be there as well because they 
are incorporated in source form into geode-core.

Please consider above suggestions for next time.

+0

On 1/4/22, 2:19 PM, "Dan Smith"  wrote:

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.

Voting deadline:
3PM PST Tuesday, Jan 11, 2022.

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%7Cdasmith%40vmware.com%7Cda7685c734334a01854f08d9cfe896aa%7Cb39138ca3ce

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

[Dan Smith]

This is the same release I started a VOTE on in December and canceled due to 
Christmas. Here was my earlier comment on where this release is coming from:

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://www.apache.org/legal/release-policy.html


From: Dan Smith 
Sent: Tuesday, January 4, 2022 2:18 PM
To: dev@geode.apache.org 
Subject: [VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

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.

Voting deadline:
3PM PST Tuesday, Jan 11, 2022.

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%7Cdasmith%40vmware.com%7C4ea1c82a07a348a28efe08d9cfd03470%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769315404324461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vdEwrWUbhikvadJb1AYHQt2wannGXODwa%2Ft2l2TXtnQ%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%7Cdasmith%40vmware.com%7C4ea1c82a07a348a28efe08d9cfd03470%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637769315404324461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6KCZtjdYZ%2FhCCMO6H6NGeSWL0DcQBYvkS3xRxWkh5B8%3Dreserved=0

Command to build the connector:
mvn package

Thanks!
-Dan

[VOTE] - Apache Geode Kafka Connector 1.1.0 - Take 2

[Dan Smith]

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.

Voting deadline:
3PM PST Tuesday, Jan 11, 2022.

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

Source and Binary Distributions: 
https://dist.apache.org/repos/dist/dev/geode/kafka-connector-1.1.0/
Github: https://github.com/apache/geode-kafka-connector/tree/rel/v1.1.0

Command to build the connector:
mvn package

Thanks!
-Dan

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

[Dan Smith]

Looking at KnownVersion.java - we did make protocol changes in 1.12.1 and 
1.13.2. So, my suggestion would be to keep 1.12.0 and 1.13.1, but dop all the 
other patch versions that aren't the latest.

-Dan

From: Dan Smith 
Sent: Monday, January 3, 2022 10:37 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

+1 - this seems reasonable to me. If we do make a protocol change in a patch, 
we could potentially keep around an older patch version just in that specific 
case, but otherwise I think this makes sense.

-Dan

From: Anthony Baker 
Sent: Thursday, December 23, 2021 8:53 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

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%7Cdasmith%40vmware.com%7Cff2c00ff1af142cd1bbd08d9cee82048%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637768318660654753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=4ykbbBS3aRaZe2HwN%2BZ3kXINab%2F%2FfyLx%2Fld5TFH%2B1zc%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] proposal to pare down old-version testing

[Dan Smith]

+1 - this seems reasonable to me. If we do make a protocol change in a patch, 
we could potentially keep around an older patch version just in that specific 
case, but otherwise I think this makes sense.

-Dan

From: Anthony Baker 
Sent: Thursday, December 23, 2021 8:53 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] proposal to pare down old-version testing

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%7Cdasmith%40vmware.com%7Ca2aa64ae94d145b7f0d008d9c634ca53%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637758752301700154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=m09xNUntRb4V3YW8zbFTq1XCYMNnqR38%2B2goSoDlxcY%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: [VOTE] - Apache Geode Kafka Connector 1.1.0

[Dan Smith]

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%7Cdasmith%40vmware.com%7Cbf17ac4182804d905cd808d9c0cafa25%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637752800287517155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=vqPY%2FHrsXAL8v27aNg2HJWLJ3wgYSESV4qgrzVQ6BOA%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%7Cdasmith%40vmware.com%7Cbf17ac4182804d905cd808d9c0cafa25%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637752800287517155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=OeFHkUzTxD9TpTWsQhQK8pAvQPKElw6nDJ5y6h8Tgqo%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%7Cdasmith%40vmware.com%7Cbf17ac4182804d905cd808d9c0cafa25%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637752800287517155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=RSR11lKzOA934RPU51rmLiUoIDhlarkAAKX3Ye5TSnc%3Dreserved=0

Command to build the connector:
mvn package

Re: [VOTE] - Apache Geode Kafka Connector 1.1.0

[Dan Smith]

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://www.apache.org/legal/release-policy.html.

-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%7Cdasmith%40vmware.com%7C4193eea06e6447ac697008d9c0c9e8a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752795694599729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=A%2Btmhypx13HzF10U%2B5gEo3P%2F2GCdrbm3JC9cZAr8HGY%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%7Cdasmith%40vmware.com%7C4193eea06e6447ac697008d9c0c9e8a4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637752795694599729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=PdLRRAIh%2FN%2B66PY9jPkdyVrIUI5rSsBPfbHTskwhSVU%3Dreserved=0

Command to build the connector:
mvn package

[VOTE] - Apache Geode Kafka Connector 1.1.0

[Dan Smith]

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://dist.apache.org/repos/dist/dev/geode/kafka-connector-1.1.0/

Github: https://github.com/apache/geode-kafka-connector/tree/rel/v1.1.0

Command to build the connector:
mvn package

Re: ANNOUNCE : Apache Geode Kafka Connector v1.1.0

[Dan Smith]

Hi Naba,

Thanks for patching log4j in the kafka connector!

However, I think we should be following the official apache release policy [1] 
for this connector, which means a VOTE requiring 3 PMC signatures, signed 
artifacts, releasing the artifacts first on the apache downloads site, etc.

In this case, I think the thing to do is retroactively vote on the release you 
created. I can help create a VOTE email tomorrow with signatures and staging 
artifacts if you like. On the off chance something comes up in the VOTE that 
requires a change we can just release an official 1.1.1 release.

[1] https://www.apache.org/legal/release-policy.html



From: Nabarun Nag 
Sent: Wednesday, December 15, 2021 9:52 AM
To: dev@geode.apache.org 
Subject: ANNOUNCE : Apache Geode Kafka Connector v1.1.0

Hi all,

I would like to announce that Apache Geode Kafka Connector v1.1.0 has been 
released. This is also available in Confluent Hub.

Notable changes are upgrading of Log4J libraries to 2.16.0 and Apache Geode 
libraries to 1.12.6.

Binaries and source code are available at: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%252Fv1.1.0data=04%7C01%7Cdasmith%40vmware.com%7C0a84317d37404103207208d9bff3adac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751875583381659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IGErV1vttsiPUVhVcO2eGwH97KFrdE6veSJOfUpTUOY%3Dreserved=0

Regards
Nabarun Nag
[https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopengraph.githubassets.com%2Fc2a01e14394ffb0f85e3ec2470786eb2d8c1ab16f34bbcddea1ccdbf7549a9ef%2Fapache%2Fgeode-kafka-connector%2Freleases%2Ftag%2Frel%2Fv1.1.0data=04%7C01%7Cdasmith%40vmware.com%7C0a84317d37404103207208d9bff3adac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751875583381659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=d2UgIG%2B%2FqjOBZl%2BAdUUt%2BbaoLe277BTOI20V2HFYw60%3Dreserved=0]
Release v1.1.0 · 
apache/geode-kafka-connector
Upgraded Log4j to 2.16.0 Apache Geode upgraded to 1.12.6
github.com

Re: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1

[Dan Smith]

+1

Ran geode-release check to build from source and validate signatures on my 
machine.

I looked into the 1.13 pipeline failure in the upgrade-test-openjdk11 job. I 
think the tests are failing due to resource issues - we see messages about 
missing heartbeats, etc. Ordinarily I would say we should wait until we can get 
that job green. However, given, the severity of the log4j issues, the fact that 
only product code that that changed was the log4j version, which only includes 
the one CVE, and these tests passed with java 8 I'm ok releasing this.

-Dan

From: Jinmei Liao 
Sent: Wednesday, December 15, 2021 11:08 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1

+1

From: Nabarun Nag 
Date: Wednesday, December 15, 2021 at 10:34 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1
+1 to 1.13.6.RC1


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


From: Owen Nichols 
Sent: Tuesday, December 14, 2021 6:19 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.6.RC1.
This release contains only a log4j bump to 2.16.0.

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

Expedited Voting deadline:
3PM PST Wed, December 15 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.6data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6wnLFaXC9qlDg6RNcCDE2nscrLTyJKtuSwAP6l7m76A%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.6.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=bZQgIvLSBt%2FtE4nUIG2luoop3W9v5mwkyHhcOSPxzts%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1121data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qdPg3TYjzgp2KiH3BdORgEs14%2B0CN%2BjybWPmC%2FK9dhA%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2%2F5l%2FEIeNnSS4P4Km8y%2FDsuXIcp9j4NoKzq4kzgk6kc%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=10zf1zJTlwYJkBaCEz35yGFbCSpTr8geNS1Fd8BiaKU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=cWewTgY49awlCwFmwZSACakETPiH%2Fl4uA4wWhaUXcpU%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.6.RC1data=04%7C01%7Cdasmith%40vmware.com%7C864a131013b142dbd40b08d9bffe594e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751921426797651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Rq%2B6SOi4VHeGXWEsbP839IfDIkc0qbfkcwFPfzjEoxA%3Dreserved=0

Pipelines:

Re: [VOTE] Apache Geode 1.14.2.RC1

[Dan Smith]

+1 to 1.14.2.RC1

Ran geode-release check to build from source and verify signatures on my 
machine.

-Dan

From: Nabarun Nag 
Sent: Wednesday, December 15, 2021 11:00 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Apache Geode 1.14.2.RC1

+1 to 1.14.2.RC1


  *   Build from source
  *   WAN clusters with SSL
  *   puts/gets
  *   validate data integrity after rolling restart.

Regards
Nabarun Nag


From: Owen Nichols 
Sent: Tuesday, December 14, 2021 6:19 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.14.2.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.14.2.RC1.
This release contains only a log4j bump to 2.16.0.

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

Expedited Voting deadline:
3PM PST Wed, December 15 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.2data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3AsLw%2BpXtq3igEj4ZOqIUVOb7v0%2BZupbn6yuS9SvodI%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.2.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=eJ2kOX8YyYmmb%2BIVcT%2BD3MMqZcBWE6C2bMPHxq1zzWM%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1122data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WqpMQuUFWUEnUQ3tuIwCHwHJgQWylB9AO2GOtXLTQ78%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6gYlqaeZlMrvnlOqrDrlzgGi1Wc6A%2BGNFIG3Wr8w8LQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6XhJoHgeY8mAavVfcEtJh79B492qtAwxY5OOWLGCltE%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TxOWuKAZ8pRY6c2hAe6teoWOBXPHbGVkTgtMCxwuUFs%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Aa8qIl%2BO%2F8AM29kmpGMoD6tE1F7NhA%2F2K5IUfPzTeEM%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5DLBVWh1Mcq%2BJrS7MzMoecw8ZfN8vhCs9Cw%2FpoNUTK0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cdasmith%40vmware.com%7Cccced4cb76664a7e332908d9bffd2d60%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751916383914127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xCf9NSHv21RK0FJMJHArNJKvEF1arw8%2FTyqAq51bKAU%3Dreserved=0

Geode's KEYS file containing PGP keys we use 

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.7.RC1

[Dan Smith]

+1

Ran geode release check to validate sigs and build from source on my own 
machine.

-Dan

From: Owen Nichols 
Sent: Tuesday, December 14, 2021 6:19 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.7.RC1

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.12.7.RC1.
This release contains only a log4j bump to 2.16.0.

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

Expedited Voting deadline:
3PM PST Wed, December 15 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.7data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=aSPwnF608ccxmd75ajwpP8gh%2BEJ7ncvFSIZx%2FfKqF7Q%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.7.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3nxViGcBEw4cjVBC%2BPVwB9BJcTCFwbGkibT9uo6K04o%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1120data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WCips3UcpUCQQJFKkjuZWeT1mNLdgYut%2FnkkfWpdkHo%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xLoIkdN7NIc9y7BnbsgTWD4qpdI%2Bq9KN%2FZoRhYm11d4%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WMJ1Hu5KFrEe5g8QN1nGBeFrT47waMfuecGd9gNCAMg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2BUwvjY3kbEUTlabl4ClpXaLECrBbyFTivyTVj7Z%2FRfI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.7.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WH5WBVAbYpsBmDttRNGumbN1g8dHzvIPcjoksKmzfDE%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ObVSks9kBWG89gaH%2FoLGYuuyasdtPMO9MJoNgipKSoY%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cdasmith%40vmware.com%7Cdb147f989d5948ea139e08d9bf715d6c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637751315889503477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MhLV8MNQU13t6qxiqe2h4HyMdV0ZyaBmkY5XPlsel0k%3Dreserved=0

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

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

[Dan Smith]

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 
Sent: Tuesday, November 30, 2021 5:53 AM
To: 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.


[cid:part1.34321273.4B069259@est.tech]


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.


[cid:part2.37771ED9.3D154D16@est.tech]


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



[cid:part3.CBE3F691.1279916D@est.tech]


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%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9854=04%7C01%7Cdasmith%40vmware.com%7Cb7d1039e109443468fb508d9b408cd8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637738772194842172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=6Vulpvvh4LsjagU7julIxqYp5%2F%2FkIBzcOikG8jrOKWc%3D=0>

https://github.com/apache/geode/pull/7145<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7145=04%7C01%7Cdasmith%40vmware.com%7Cb7d1039e109443468fb508d9b408cd8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637738772194852171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=nA%2FNGaOEg1sR8yYpRUHkhfupciFhhMfwiPyhGv%2BSHnw%3D=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 themselves, I don't think we are keeping the contents of the .drf 
files in memory, except during recovery time.

-Dan

From: Jakov Varenina <mailto:jakov.varen...@est.tech>
Sent: Wednesday, November 24, 2021 11:13 AM
To: dev@geode.apache.org<mailto:dev@geode.apache.org> 
<mailto:dev@geode.apache.org>
Subject: Question related to orphaned .drf files in disk-store

Hi devs,

We have noticed that disk-store folder can contain orphaned .drf files (only 
.drf file without accompanying .crf and .krf file with the same id). Also, we 
have noticed that these "orphaned" .drf are stored in heap (drfOnlyOplogs hash 
map with size 7680 in below picture):

[cid:part1.46E308C2.37688A13@est.tech]

Could you please tell us why do geode after compaction sometimes only keep .drf 
and deletes the .crf and .krf files? Why do geode need those orphaned .drf 
files?

BRs/Jakov

Re: Client terminating when trying to connect to an SSL configured locator

[Dan Smith]

I guess the alternative would be for the client to automatically switch to SSL 
if it detected the server was using SSL? It is not currently doing that, as you 
discovered.

That might be a nice feature to have to support upgrading to SSL. At some 
point, it is important for users that want SSL to configure their client to 
only​ use SSL, to prevent downgrade attacks.

I think we would consider a geode change that turns on SSL by default to be a 
breaking change. I can image some users might want to upgrade to using SSL in 
their existing cluster. For clients, I think that could be accomplished by 
running both a SSL and non-SSL enabled locator, for example. I'm not sure if 
it's possible to switch the P2Pmessaging to use SSL with a rollng upgrade right 
now though.

-Dan

From: Mario Salazar de Torres 
Sent: Tuesday, November 30, 2021 10:37 AM
To: dev@geode.apache.org 
Subject: Client terminating when trying to connect to an SSL configured locator

Hi everyone,

During some tests, we've noted that if a client tries to connect to an SSL 
configured locator, and the client does not have SSL configured, it terminates 
due to an unhandled exception.
You can check the behaviour here for geode-native: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fblob%2Fdevelop%2Fcppcache%2Fsrc%2FThinClientLocatorHelper.cpp%23L147data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373842079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=q%2F18j0f3GtCXUS5jtI8fZbdjUFn7ouRwRd%2BnAKFA9QY%3Dreserved=0
And here for the Java client: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-tcp-server%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Fdistributed%2Finternal%2Ftcpserver%2FTcpClient.java%23L278data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373852076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZkixzNe4sGUzIQOz%2FNc1gdYBI%2B6F%2FFeG2HsPf3ZaYVU%3Dreserved=0

And here is the question. Do you know if there is any reason behind it?
Also, do you happen to know if there is any upgrade case in which SSL is 
enabled on the newer version? Because I am guessing this kind of upgrade might 
be problematic, right?

Thanks!
Mario

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

[Dan Smith]

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 themselves, I don't think we are keeping the contents of the .drf 
files in memory, except during recovery time.

-Dan

From: Jakov Varenina 
Sent: Wednesday, November 24, 2021 11:13 AM
To: dev@geode.apache.org 
Subject: Question related to orphaned .drf files in disk-store

Hi devs,

We have noticed that disk-store folder can contain orphaned .drf files (only 
.drf file without accompanying .crf and .krf file with the same id). Also, we 
have noticed that these "orphaned" .drf are stored in heap (drfOnlyOplogs hash 
map with size 7680 in below picture):

[cid:part1.46E308C2.37688A13@est.tech]

Could you please tell us why do geode after compaction sometimes only keep .drf 
and deletes the .crf and .krf files? Why do geode need those orphaned .drf 
files?

BRs/Jakov

Re: API check error when adding a new method to a public interface

[Dan Smith]

First off, it's not reasonable to say that we will not add any new methods to 
the public API unless we release a new major version. We will continue to add 
methods to the public API, which is something we've been doing in pretty much 
every minor version.

Our practice has been to make sure that we provide default implementations of 
methods added to interfaces that are used for callbacks - for example 
CacheListener or SecurityManager. These are interfaces that a user implements 
and geode calls into, so if a user upgraded to a new version their code would 
be broken without a default method.

We don't do that for interfaces that are not callbacks. For example Cache, 
Region, or GatewaySender. Users don't inject their own implementations of these 
interfaces into Geode. I guess we could implement default methods when adding 
to these classes, but I don't think it really makes sense. You could argue 
these interfaces should have been final classes, but that would make it harder 
for folks to mock them in tests.

For this specific case, though, I'm not sure if we need a method on 
GatewaySender? Alberto, if you want to add a method that is only called by 
internal code like the create gateway sender command, I think it would be 
better to add that method to the InternalGatewaySender interface.

-Dan

From: Owen Nichols 
Sent: Tuesday, November 23, 2021 10:42 AM
To: dev@geode.apache.org 
Subject: Re: API check error when adding a new method to a public interface

Adding a new method to a public interface breaks anyone else implementing that 
interface, for example Spring.

Adding a new method with a default implementation (except in the case where it 
is purely a composure of existing methods) isn't great either, you would 
probably have to throw Unsupported exception in the default implementation, 
which just pushes the mismatch from compile-time to runtime.  Default methods 
can also still be problematic if existing implementations of the interface 
happened to already have a method with the same name.

One option for adding new public methods would be to make a proposal for a new 
major version Geode 2.0.

Another option to consider is creating a new interface (rather than adding to 
existing interface).  Then change existing impl classes to implement both.

 -Owen

On 11/23/21, 10:33 AM, "Anilkumar Gingade"  wrote:

Alberto,

I don’t think the intention is to avoid, discourage adding a new 
method...As you have seen any changes to the API or adding a new API has 
implications on other parts of the product, it is good to validate/verify and 
address the dependency across the product and get everything working in 
accordance (without breaking any compatibility). If you have any requirement 
please propose through RFC and get an approval.

-Anil.

On 11/23/21, 8:44 AM, "Alberto Gomez"  wrote:

Hi,

After the introduction of GEODE-9702 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9702data=04%7C01%7Cdasmith%40vmware.com%7C9c70bfb452644c3a670908d9aeb1183f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637732897909772680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WkedxqEIQP3jB6rg9sTS%2FYfwsD%2BlQolQ8zxi6h50PRA%3Dreserved=0),
 adding a new method to a public interface will make the 
api-check-test-openjdk11 fail even if a default implementation is provided.

My question is if the goal of this change is to forbid this type of 
changes in minor versions or if there is a process to follow in order for 
changes of this type to be added.

I wanted to propose (in an RFC) the addition of a new parameter to the 
create gateway sender command that would require adding a new method to the 
GatewaySender interface as well as to other public interfaces and I was 
wondering if this will be possible at all, and if so, how should I proceed with 
it.

Thanks,

Alberto

Re: Added to Jira

[Dan Smith]

Done! You should have access now.

-Dan

From: Kristen Oduca 
Sent: Tuesday, November 16, 2021 4:03 PM
To: dev@geode.apache.org 
Subject: Added to Jira

Hi,

Can I be added to the Geode Jira so I can assign myself tasks? My username is 
kris10.

Thanks,
Kristen Oduca

[DRAFT] Geode Board Report due by Wednesday Nov 10th

[Dan Smith]

This is a draft of our report to the board. I will submit it by 5PM Thursday if 
no one objects. Please let me know if there are details you'd like me to add!

-Dan

## 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 Board-level issues at this time.

## Membership Data:
Apache Geode was founded 2016-11-15 (5 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:

We issued two releases this quarter, including a new minor 1.14 that took
about 9 months from the time the branch was cut. We're hoping to have
a much shorter release time for 1.15.0, which is in development.

Recent releases:
- 1.14.0 was released on 2021-09-03.
- 1.12.5 was released on 2021-10-27.

## Community Health:

Initiatives during this period include:
- Continuing our monthly video conferences
- Gregory Green presented on "OLTP Application Data Services with Apache Geode" 
at apachecon

Re: [VOTE] Apache Geode 1.12.5.RC1

[Dan Smith]

+1 to 1.12.5.RC4. Reviewed changes, geode-release-check.

-Dan


From: Dave Barnes 
Sent: Thursday, October 21, 2021 3:30 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] Re: [VOTE] Apache Geode 1.12.5.RC1

+1 docs check out: javadocs, user guide (manual build), user guide (script
build)


On Wed, Oct 20, 2021 at 4:33 PM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.5.RC4.
> Earlier RC1, RC2 and RC3 had issues.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Mon, October 25 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.5.RC4
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.5data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9jFPqvwrmyWMn23njnHopg7LfHO7m7Eaal29zlSwiJA%3Dreserved=0
>
> Source and binary distributions:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.5.RC4%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=htvLpeWy%2Fu3OVMa41RCuWpZXk%2FL6%2FWu1gGawIn72Uv4%3Dreserved=0
>
> Maven staging repo:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1113data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=JR8VUof0qNYjv2dcorfWehVDcIp2i2CPMGHbSCYpqrs%3Dreserved=0
>
> GitHub:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=of69EZAtjuVzKjLEACdtTAIRkzX9kltfjumVNysILQo%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=K97kwwb2yDeAUwL0a4DHsrQMstzKIFwf9owaUqpSrAw%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kFQcb7NIY%2FI%2B0%2BXuO50UqslEzJN%2F0Lf37g7OOt5egY4%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.5.RC4data=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VDtt6srAnhNsq7itRe2W47DPsZTaYcckMrA8Ig%2FNiAU%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=4MBgs9JNve3rUrp5HOls1OBueloIVVm2zO1ZgM9Aico%3Dreserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rcdata=04%7C01%7Cdasmith%40vmware.com%7C485abffa5ee14da1451f08d994e263be%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637704522333800844%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=AtSKs4gVmeb7h4a9pisWli68oBrwfn48a1vYHwFMq28%3Dreserved=0
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> 

Re: Region is not created on one of the servers

[Dan Smith]

I think maybe a better option might be to use a lock for the cluster 
configuration. We can make the request to get the cluster config wait until the 
update to the cluster config is completely applied. Maybe we already have a 
lock to force cluster configuration updates to happen one at a time?

-Dan

From: Mario Kevo 
Sent: Tuesday, October 12, 2021 1:35 AM
To: dev@geode.apache.org 
Subject: Odg: Region is not created on one of the servers

The new ticket is opened.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9718data=04%7C01%7Cdasmith%40vmware.com%7C712ca6480e4642cb8dd108d98d5b3ac0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637696245240683976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Q4suASyMhog5N8ZWdBH266udGFxe9MBQVMKEkms1zhM%3Dreserved=0

There are two proposals on the ticket, so it should be decided in which way we 
should go.

BR,
Mario

Šalje: Udo Kohlmeyer 
Poslano: 12. listopada 2021. 0:59
Prima: dev@geode.apache.org 
Predmet: Re: Region is not created on one of the servers

Hi Mario,

I think your assessment of the problem is correct. Thinking about it, there is 
no simple (correct) way to easily solve this. Given that there are too many 
variables in play, users making configurational changes, whilst servers are 
coming up.

Now, that said, I think we should address this problem. I also think your 
assessment is correct that cluster configuration was not written to handle this 
scenario. I think some thought has to go into the algorithm that one would like 
to follow and how we would like to resolve it.

Can you please raise a ticket on this issue.

--Udo

From: Mario Kevo 
Date: Monday, October 11, 2021 at 11:27 PM
To: dev@geode.apache.org 
Subject: Odg: Region is not created on one of the servers
I think that there can be a problem if we change to first add it to cluster 
config and then do distribution to existing servers.

Now, when the "create region" command is executed it got all servers from the 
view and sends all of them to start creating a region with parameters specified 
in the command.
The region creating is started on all servers and after it is finished, it is 
added to the cluster configuration. In case there are some problems with 
creating a region(wrong parameter used or something else) it will not create a 
region on the existing servers and will not write anything in a cluster 
configuration.

In case we decide to change order, it will write in the cluster config before 
the command is successful, and then we should have some backup to rollback 
cluster configuration.

Also, this can happen for all commands that editing cluster configuration.

It looks like this is not designed to execute some commands in parallel with 
starting servers.

BR,
Mario
____
Šalje: Dan Smith 
Poslano: 8. listopada 2021. 20:37
Prima: dev@geode.apache.org 
Predmet: Re: Region is not created on one of the servers

This seems like something ought to work, so I would call it a bug if the region 
didn't get created on 1 server. At first glance, it looks like the problem is 
that we distribute the region to all the servers before adding it to cluster 
config? Seems like we need to do distribution after​ adding the region to 
cluster config, to make sure that all servers get the region.

-Dan

From: Mario Kevo 
Sent: Friday, October 8, 2021 5:31 AM
To: dev@geode.apache.org 
Subject: Region is not created on one of the servers

Hi geode-dev,

We are using a system with a large number of servers.
While starting all servers, in parallel, we create a region through gfsh.
The problem is that on one of the servers region is not created.

There is an example of the problem:

We started the locator, and then go with starting the servers, one by one.
In the meantime, we run the "create region" command through gfsh.
All servers that are started before the "create region" command got information 
to create a region on itself, but the problem is in the server which is started 
after the "create region" command is started and not finished yet.
After the "create region" command is finished, all other servers started after 
that will get that region in the cluster configuration and create it.

What happened with this one server without a region?
It is started after the "create region" command is started, so it will not get 
information to create a region on itself from the locator. Also, the cluster 
configuration doesn't have that information yet, so the server cannot read it 
from the received cluster configuration.

So the question is, is it allowed to run commands in parallel?
If yes, we should do some checks in the code to avoid this issue.
If not, we need to write it somewhere in the documentation.

BR,
Mario

Re: Geode-9621: Spotless overstepping its boundary of formatter

[Dan Smith]

>The formatter now throws when there is a naked version-string on the 
>dependency line, as we discussed.

This new behavior seems reasonable to me. And I think this is what you are 
asking for, Udo? I do agree that spotlessApply shouldn't change any behavior 
and cause someone to lose part of their changes as a result.

-Dan


From: Udo Kohlmeyer 
Sent: Monday, October 11, 2021 5:32 PM
To: dev@geode.apache.org 
Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter

Hi there Robert,

Yes, you did work with me, but the solution to add my custom versions of jars 
that I want to test with, into the `DependencyConstraints` file just feels like 
the wrong approach. The prior art you refer to, is a specific version of  
tomcat we want each module to use. It is no different to specifying the exact 
artifact version we want for production code. My case is that I don’t want my 
artifact version dependencies to leak outside of the test module.

I think, the fact that the decision to elevate spotless from cosmetic formatter 
to actually having a significant impact, was done unilaterally. Please don’t 
get me wrong, I love the fact that we want to fix the problem where developers 
are not following good practices. But I think I am digging in here, because I 
believe we missed an opportunity to get more voices in this decision.

I also firmly believe that spotless is overstepping the “cosmetic” boundary. I 
think many developers would feel upset if their code were to be changed. If 
spotless suddenly replaces a for-loop with a stream implementation.

I think it is one thing to decide if gradle should be formatted with 2 spaces 
vs 4, or when and how lines wrap, and it’s another for spotless to just remove 
version information and force one consistent version even if the version was 
specifically overriden.

I wonder if we can maybe reduce the area of effect of this change and really 
only force the version formatter to activate for the ‘main’ configuration and 
leave every other configuration type (test, distributedTest, integrationTest, 
acceptanceTest, upgradeTest) alone.

--Udo

From: Robert Houghton 
Date: Tuesday, October 12, 2021 at 10:38 AM
To: dev@geode.apache.org 
Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter
Currently there is no way to exclude certain code blocks from the malicious 
code formatter. Therefore, my tests that require a specific hardcoded version 
of Spring to be used, will always either fail the validation or tests will fail 
due to spotless changing my testing scenario by affecting the version of the 
library that we have to use.


Udo,

I have worked with you to accomplish your goal of not automatically “fixing” 
the inclusion of dependency versions in the build files, as your work case 
wants to do something special there. The formatter now throws when there is a 
naked version-string on the dependency line, as we discussed.

If you want to continue to work around this, there are many cases of prior art 
in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific 
versions are allowed.

Good luck.
-Robert Houghton

Re: Region is not created on one of the servers

[Dan Smith]

This seems like something ought to work, so I would call it a bug if the region 
didn't get created on 1 server. At first glance, it looks like the problem is 
that we distribute the region to all the servers before adding it to cluster 
config? Seems like we need to do distribution after​ adding the region to 
cluster config, to make sure that all servers get the region.

-Dan

From: Mario Kevo 
Sent: Friday, October 8, 2021 5:31 AM
To: dev@geode.apache.org 
Subject: Region is not created on one of the servers

Hi geode-dev,

We are using a system with a large number of servers.
While starting all servers, in parallel, we create a region through gfsh.
The problem is that on one of the servers region is not created.

There is an example of the problem:

We started the locator, and then go with starting the servers, one by one.
In the meantime, we run the "create region" command through gfsh.
All servers that are started before the "create region" command got information 
to create a region on itself, but the problem is in the server which is started 
after the "create region" command is started and not finished yet.
After the "create region" command is finished, all other servers started after 
that will get that region in the cluster configuration and create it.

What happened with this one server without a region?
It is started after the "create region" command is started, so it will not get 
information to create a region on itself from the locator. Also, the cluster 
configuration doesn't have that information yet, so the server cannot read it 
from the received cluster configuration.

So the question is, is it allowed to run commands in parallel?
If yes, we should do some checks in the code to avoid this issue.
If not, we need to write it somewhere in the documentation.

BR,
Mario

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Dan Smith]

My understanding from our previous discussion about upgrading lucene was that 
we talked about pausing the asynchronous indexing process during the rolling 
upgrade. I don't remember a discussion that it was ok to not allow queries 
during the upgrade. But this is what we added to the docs:

"All cluster members must be running the same major Lucene version in order to 
execute Lucene queries."

What happens if a user runs a query during the rolling upgrade and why do we 
need to have this restriction? It seems to me like at a minimum we need to 
allow queries during the upgrade.

We also should consider what will happen to users with server-side query or 
indexing code - will they be able to upgrade or are they likely to hit breaking 
changes in the Lucene API?

-Dan

From: Nabarun Nag 
Sent: Tuesday, September 28, 2021 7:13 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Upgrading to Lucene 7.1.0

But Mario, just for my clarification, if we re-enable the queries in the tests 
in the mixed version servers mode, it goes into a stackoverflow situation. That 
what i saw when i set hasLuceneVersionMismatch(host) to false in the test so 
that it does the query.

Regards
Naba


From: Mario Kevo 
Sent: Tuesday, September 28, 2021 4:49 AM
To: dev@geode.apache.org 
Subject: Odg: [DISCUSS] Upgrading to Lucene 7.1.0

Hi all,

Just a small clarification of the reverted PR.

There were a lot of changes between Lucene versions 6.x and 7.x. There is an 
article for that 
Upgrading+to+Lucene+7.1.0.

The first larger change was in the scoring mechanism. We adapt it to one that 
is correct for us. (verified by DistributedScoringJUnitTest)

The main change was in Lucene index format. There we come into a problem with 
our tests.
Lucene 6.x cannot read the index format of Lucene 7.x.
Through PRs we decided to include Lucene uplift in Geode 1.15.0 and add check 
if all members are on 1.15.0 version or higher (after uplift Lucene to a newer 
version with index format changes this should be changed). If a check is passed 
it will allow doing Lucene query, if not there will be a printed log that not 
all members on 1.15.0 or higher version.

Also, you can found a discussion on dev list from 2 years ago about Lucene 
upgrade: Lucene 
Upgrade

BR,
Mario




Šalje: Udo Kohlmeyer 
Poslano: 28. rujna 2021. 1:44
Prima: dev@geode.apache.org 
Predmet: Re: [DISCUSS] Upgrading to Lucene 7.1.0

Might I propose something here.

There is currently a significant amount of work going into completing 
Geode-8705, which is the Classloader isolation. We are currently targeting to 
getting this release in Geode 1.16.

My proposal is, that we use the capability that Patrick demo’d at the Community 
meeting (on this topic) where one, at runtime, can unload /  load extensions 
(like our integration with Lucene). This means that one could possibly do a 
rolling upgrade on the existing system, and keep the versions of the Lucene 
integration stable.

Once the whole system has been upgraded, the existing Lucene extension 
component is then unloaded, and the newer version of the extension component is 
then loaded. What this means, is that at runtime, there will be a period of 
time where Lucene queries will not be available and as part of the “load” 
lifecycle of the extension, there needs to be an initialization step, which 
will initialize the extension component safely.

Once initialized, Lucene queries can then become available again, etc.

This if course requires some work around the lifecycles of extension components 
and making sure that I can add the extension on at runtime and safely 
initialize it.

I think this approach allows for a more seamless (lower downtime) upgrading of 
system and extension components.

Thoughts?

--Udo

From: Nabarun Nag 
Date: Tuesday, September 28, 2021 at 

Re: [DISCUSS] Upgrading to Lucene 7.1.0

[Dan Smith]

Does anyone have more context on why lucene queries won't work during the 
rolling upgrade? I can see what added a line to the documentation and changed 
the tests not to do queries, but I'm not sure why we needed to do that.

-Dan


From: nabarun nag 
Sent: Monday, September 27, 2021 11:48 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Upgrading to Lucene 7.1.0

Hi dev team,

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

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

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

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

Regards
Nabarun.

Re: [DISCUSS] Remove geode-dotnet-core-client repo

[Dan Smith]

Ok. I created an INFRA ticket to delete the repo - 
https://issues.apache.org/jira/browse/INFRA-22301

-Dan

From: Blake Bender 
Sent: Thursday, September 2, 2021 9:29 AM
To: dev@geode.apache.org 
Subject: RE: [DISCUSS] Remove geode-dotnet-core-client repo

Please do.  We created this repo early on, when we thought .net core made more 
sense in it's own repo rather than as part of the native client repo.  Since 
then, we've decided to put it in geode-native because we frequently have to 
update both C bindings and .net core pinvokes at the same time, and keeping the 
two repos in sync would be untenable or at least very difficult.  Thus 
geode-dotnet-core-client is not in use and never really was, actively.

Thanks,

Blake


-Original Message-
From: Dan Smith 
Sent: Thursday, September 2, 2021 9:18 AM
To: dev@geode.apache.org
Subject: [DISCUSS] Remove geode-dotnet-core-client repo

It looks like the geode-dotnet-core-client repository is stale, and the code 
has moved to the geode-native repository. Is it ok to go ahead and remove the 
geode-dotnet-core-client repository? If so, I'll figure out how to make that 
happen. At a minimum we could commit a change that deletes all the code and 
leaves a README pointing to the new location.

Old Location: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-client%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cd94cf9d32deb44246b9508d96e2ee547%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661969972140103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YhnzzFWyzJaY096q53ikcN1dJqi%2BkUvVESFPB3lUQ8E%3Dreserved=0
New Location: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Fdevelop%2Fnetcoredata=04%7C01%7Cdasmith%40vmware.com%7Cd94cf9d32deb44246b9508d96e2ee547%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661969972140103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1A14kw%2BzUobx48xO%2BW4YjcKpXsv7mYzcXAHFHpSzytE%3Dreserved=0

-Dan

Re: testing Geode Net Core

[Dan Smith]

It does look like maybe you are trying to use the geode-dotnet-core-client 
repository, which is stale. There is a separate thread ongoing to delete that 
repo. The net-core client work is now happening in the geode-native repo, which 
doesn't have this hardcoded c:/Users/bblake/ path!

-Dan

From: Ernie Burghardt 
Sent: Tuesday, September 7, 2021 10:33 AM
To: dev@geode.apache.org 
Subject: Re: testing Geode Net Core

Hi Rupert,

We are very early in development of net-core, I would watch for a future 
release or monitor the pull requests as features are added…

Best,
Ernie

From: Rupert St John Webster 

Date: Tuesday, September 7, 2021 at 8:25 AM
To: dev@geode.apache.org 
Subject: testing Geode Net Core
Hi,

When I try and test the Net Core client, and create a cache factory as per 
native client:

CacheFactory cacheFactory = new CacheFactory();

I get error:

"Unable to load DLL 'c:/Users/bblake/src/nc_install/bin/apache-geode-c.dll' or 
one of its dependencies: The specified module could not be found. (0x8007007E)"

Can this be resolved please?

Thanks 

[DISCUSS] Remove geode-dotnet-core-client repo

[Dan Smith]

It looks like the geode-dotnet-core-client repository is stale, and the code 
has moved to the geode-native repository. Is it ok to go ahead and remove the 
geode-dotnet-core-client repository? If so, I'll figure out how to make that 
happen. At a minimum we could commit a change that deletes all the code and 
leaves a README pointing to the new location.

Old Location: https://github.com/apache/geode-dotnet-core-client/
New Location: https://github.com/apache/geode-native/tree/develop/netcore

-Dan

Re: Request JIRA contributor permissions

[Dan Smith]

You should have permissions now. Welcome!

-Dan

From: Eric Zoerner 
Sent: Wednesday, September 1, 2021 4:49 PM
To: dev@geode.apache.org 
Subject: Request JIRA contributor permissions

I am a new developer on the Geode project and need permissions to assign 
tickets to myself and move them into the current iteration.

Thanks,
Eric

Re: [VOTE] Apache Geode 1.14.0.RC2

[Dan Smith]

+1

-Dan


From: nabarun nag 
Sent: Tuesday, August 31, 2021 5:36 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.14.0.RC2

Hello Geode Dev Community,

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

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

Voting deadline: Please note that this is an expedited voting process
3PM PST Thur, September 02 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.14.0data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387006295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FPKFGzglq8z8v6yPQpzX4bv0ZV2VddoETC2ftYo70NM%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.14.0.RC2%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387006295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hKBnLbg7NDNd%2BkAMVXrwoyAijK330%2FWbYY24oeZTZlU%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1098data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9vek%2FQH%2BruR2PH0i7drzv%2FKdEDk%2BgWdijjzh4Pg9%2BJc%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VW7CLSeWdaCsR8llsnLak%2FTZJnNH73QWYdMuGsKduYk%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qAKbmfQPHSGA%2B2Xf55lvMV%2FhE%2FgyQgHBI7sENBHldIQ%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=A%2FdqUysuYvaGVhO%2Fh1vveuar8iceP2HzPajrYinH9Kg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.14.0.RC2data=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yR0LyWUgm1vekKm%2Bzl9c1%2Bctag%2BEQ%2BtIy2r2DszyYWI%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-maindata=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3EKTOQP9%2BMpDacppkZ8xICDGwa8RLEifl0yK69h3zvI%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-14-rcdata=04%7C01%7Cdasmith%40vmware.com%7C028e1ccc95494d03f34108d96ce0a592%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637660534387016291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6xvt%2FqSRPt7QxEgAZvtgdrvYnVHdlfSAW9YUZBczq9g%3Dreserved=0

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

[DISCUSS] Integrate Geode's redis API with the security manager

[Dan Smith]

Hi folks,

Here's a small RFC related to using the security manager with our redis API. 
Comments welcome, here or on the wiki.

https://cwiki.apache.org/confluence/display/GEODE/Integrate+Geode%27s+redis+API+with+the+security+manager

Thanks!
-Dan

Re: [DRAFT] Geode Board Report due by Wed Aug 11st

[Dan Smith]

Board report has been submitted.

Thanks!
-Dan

From: Dan Smith 
Sent: Tuesday, August 10, 2021 11:29 AM
To: dev@geode.apache.org 
Subject: [DRAFT] Geode Board Report due by Wed Aug 11st

This is a draft of the report to be submitted tomorrow -- please send me your 
feedback. Sorry for the late DRAFT, I was out last week so I only saw the 
notice this Monday that the report was due!

Thanks,
Dan

# Apache Geode Board Report

## 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 Board-level issues at this time.

## Membership Data:
Apache Geode was founded 2016-11-15 (over 5 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:
- Dan Smith replaced Karen Miller as PMC chair on 2021-05-20
- Alberto Bustamante Reyes was added as committer on 2021-05-14

## Project Activity:
Four releases of Apache Geode were issued during this reporting period. These
were patch releases fixing specific bugs. We are still working on our next
feature release, Geode 1.14, which has been taking a while to stabilize.

Work areas included:
- Ongoing work to create an endpoint that is compatible with Redis clients for 
Geode
- Ongoing work to allow user jars to be loaded in isolated classloaders on 
Geode servers
- Improvements to WAN replication
- Bug fixes

Recent releases:
- 1.12.4 was released on 2021-07-27.
- 1.13.4 was released on 2021-07-30.
- 1.12.3 was released on 2021-07-01.
- 1.13.3 was released on 2021-06-25.

## Community Health:
Initiatives during this period include:
- Starting a monthly video conference for community members to present and
  discuss topics of interest. Not used for decision making. 2 meetings held so
  far. Recordings are available on the geode wiki.

[DRAFT] Geode Board Report due by Wed Aug 11st

[Dan Smith]

This is a draft of the report to be submitted tomorrow -- please send me your 
feedback. Sorry for the late DRAFT, I was out last week so I only saw the 
notice this Monday that the report was due!

Thanks,
Dan

# Apache Geode Board Report

## 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 Board-level issues at this time.

## Membership Data:
Apache Geode was founded 2016-11-15 (over 5 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:
- Dan Smith replaced Karen Miller as PMC chair on 2021-05-20
- Alberto Bustamante Reyes was added as committer on 2021-05-14

## Project Activity:
Four releases of Apache Geode were issued during this reporting period. These
were patch releases fixing specific bugs. We are still working on our next
feature release, Geode 1.14, which has been taking a while to stabilize.

Work areas included:
- Ongoing work to create an endpoint that is compatible with Redis clients for 
Geode
- Ongoing work to allow user jars to be loaded in isolated classloaders on 
Geode servers
- Improvements to WAN replication
- Bug fixes

Recent releases:
- 1.12.4 was released on 2021-07-27.
- 1.13.4 was released on 2021-07-30.
- 1.12.3 was released on 2021-07-01.
- 1.13.3 was released on 2021-06-25.

## Community Health:
Initiatives during this period include:
- Starting a monthly video conference for community members to present and
  discuss topics of interest. Not used for decision making. 2 meetings held so
  far. Recordings are available on the geode wiki.

Re: Annual branch cleanup Aug 17

[Dan Smith]

Would it be ok to leave the feature/redis-performance-testing branch for the 
time being? That is a shared branch that is being used by several people.

Thanks,
-Dan

From: Owen Nichols 
Sent: Sunday, August 1, 2021 1:01 AM
To: dev@geode.apache.org 
Subject: Annual branch cleanup Aug 17

Reminder to use your personal fork whenever possible.  If you do create a 
branch in the geode repo, please clean it up promptly.
An easy way to check is 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fbranches%2Fyoursdata=04%7C01%7Cdasmith%40vmware.com%7Ca6240f939f1b4f6f55b108d954c29666%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637634016994411818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W0OFmlnZ%2F%2Fr6GOt9%2Fi7kwNeUuh2JpX6kAs%2BHKy8TcQU%3Dreserved=0

I propose to delete the branches listed below on August 17 at 3pm.  If there’s 
any branch you want to keep for reference, please push it to your own fork 
before then.
I will assume lazy consensus (no need to respond unless you disagree).

I will delete the following branches:
GEM-3288-network-interfaces
revert-6429-feature/GEODE-9220-set
feature/GEODE-6316
feature/GEODE-6770
feature/GEODE-7277
feature/vSphereTests
feature/GEODE-7109
feature/GEODE-8118
feature/GEODE-6901
mass-test-run
wip/throw-FDE-instead
feature/GEODE-8324
feature/GEODE-8444
feature/change-readme-ownership
feature/redis-memory-overhead
feature/redis-performance-testing
GEODE-9064-JMX-filter-support_1.12-02

I will delete the following branches and close their associated PR (please push 
to your own fork and make a new PR from there before Aug 17):
upthewaterspout-skip-checks
expireAuthentication
feature/GEODE-9191
feature/GEODE-8278-2

This branch has previously been approved by the community to remain in the 
geode repo and will NOT be deleted:
feature/GEODE-7665

Re: Volunteers to be JIRA/confluence/mailing list admins?

[Dan Smith]

Thanks for volunteering Alberto!

I went ahead and made you an administrator in JIRA and confluence. I created a 
wiki page here that outlines the steps to add new people - let me know if you 
have any questions.

https://cwiki.apache.org/confluence/display/GEODE/JIRA+and+Confluence+Administration

Thanks!
-Dan

From: Alberto Bustamante Reyes 
Sent: Wednesday, July 28, 2021 12:23 PM
To: dev@geode.apache.org 
Subject: Re: Volunteers to be JIRA/confluence/mailing list admins?

Hi,

I could help as confluence/jira admin.

Alberto B.

Obtener Outlook para 
iOS<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukefdata=04%7C01%7Cdasmith%40vmware.com%7C7d50ef74357048bf395408d951fd31a7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637630970174696885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aNHhzAdYJfY2h3X2Wj8CzdKuqjL4HLPF3QE2%2FgYKYPQ%3Dreserved=0>
____
De: Dan Smith 
Enviado: Wednesday, July 28, 2021 7:52:23 PM
Para: dev@geode.apache.org 
Asunto: Volunteers to be JIRA/confluence/mailing list admins?

Hi all,


We have a couple of admin/human spam filter jobs that I think could use a few 
more volunteers.


  *   Confluence/JIRA admins - we have a process where we grant permission to 
these resources to anyone who asks for access on the mailing list. This could 
be any committer, or really any contributor we are comfortable giving admin 
access to our confluence and/or JIRA projects.
  *   Mailing list moderators - this probably needs to be PMC members since you 
would moderate the private list.

I'd love to get some folks outside of the US time zones so we don't leave 
people outside the US waiting for a day if they need permission.

Any volunteers?

-Dan

Volunteers to be JIRA/confluence/mailing list admins?

[Dan Smith]

Hi all,


We have a couple of admin/human spam filter jobs that I think could use a few 
more volunteers.


  *   Confluence/JIRA admins - we have a process where we grant permission to 
these resources to anyone who asks for access on the mailing list. This could 
be any committer, or really any contributor we are comfortable giving admin 
access to our confluence and/or JIRA projects.
  *   Mailing list moderators - this probably needs to be PMC members since you 
would moderate the private list.

I'd love to get some folks outside of the US time zones so we don't leave 
people outside the US waiting for a day if they need permission.

Any volunteers?

-Dan

Re: Permissions to comment on RFCs?

[Dan Smith]

Hi Mario.

You should have full access to the Geode wiki now.

Thanks,
-Dan

From: Mario Salazar de Torres 
Sent: Tuesday, July 27, 2021 11:12 PM
To: dev@geode.apache.org 
Subject: Re: Permissions to comment on RFCs?

Hi,

Thanks for clarifying it. My username is "mario.salazar.de.torres"

Thanks,
Mario.
____
From: Dan Smith 
Sent: Tuesday, July 27, 2021 11:52 PM
To: dev@geode.apache.org 
Subject: Re: Permissions to comment on RFCs?

You do need permissions. What is your confluence username? If you don't have 
one you can create account. Then we can add you to the Geode project (we add 
anyone who asks :).

-Dan

From: Mario Salazar de Torres 
Sent: Tuesday, July 27, 2021 2:10 AM
To: dev@geode.apache.org 
Subject: Permissions to comment on RFCs?

Hi,

I've been trying to comment in this RFC: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FOn%2BDemand%2BGeode%2BAuthentication%2BExpiration%2Band%2BRe-authenticationdata=04%7C01%7Cdasmith%40vmware.com%7Cfdb3948353e54a3201dd08d9518ebac2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637630495735425224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DXNNwcAKZyWWDDQZRp0ByUXoIcvvgAO9J0mkkTX%2FWvc%3Dreserved=0
 but I was not able to.
Since I never commented in an RFC, I wonder if I need any kind of permissions?

Thanks,
Mario.

Re: Permissions to comment on RFCs?

[Dan Smith]

You do need permissions. What is your confluence username? If you don't have 
one you can create account. Then we can add you to the Geode project (we add 
anyone who asks :).

-Dan

From: Mario Salazar de Torres 
Sent: Tuesday, July 27, 2021 2:10 AM
To: dev@geode.apache.org 
Subject: Permissions to comment on RFCs?

Hi,

I've been trying to comment in this RFC: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FOn%2BDemand%2BGeode%2BAuthentication%2BExpiration%2Band%2BRe-authenticationdata=04%7C01%7Cdasmith%40vmware.com%7C69e621d38e264467c1a708d950de5f9a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637629738289722431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=fOu1pkkGhLhR3kiwci8FE%2FH60q7JQFIfrRdfJBawCYU%3Dreserved=0
 but I was not able to.
Since I never commented in an RFC, I wonder if I need any kind of permissions?

Thanks,
Mario.

Re: [Suspected Spam] Re: [VOTE] Apache Geode 1.12.4.RC1

[Dan Smith]

+1

Looks good to me.

-Dan

From: Dave Barnes 
Sent: Thursday, July 22, 2021 12:38 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] Re: [VOTE] Apache Geode 1.12.4.RC1

+1 for geode docs
- Checked API docs (javadocs) for correct version in page headers
- Successfully ran user guide build script

+0 for geode-native docs
+0 for geode-examples
- For these last two, the build scripts are known to be broken, in the
first case due to a Bookbinder problem and in the second case due to a
versioning mismatch in the sessionState startup script. Both of these are
known to be fixed in later releases, so they should not be showstoppers for
this release candidate.

-

On Wed, Jul 21, 2021 at 4:35 PM Dick Cavender  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.12.4.RC1.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> *3PM PST Mon, July 26 2021*
>
> Please note that we are voting upon the source tag:
> rel/v1.12.4.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.4data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=655uVvSfcvVPyXSoH%2BBemMDQnz5IWCekn5qhvsqE6Zw%3Dreserved=0
>
> Source and binary distributions:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.4.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=VzDmduNDtYoZuyAgA2g2IYzcp2ASwqffDCy7aQaJp%2FA%3Dreserved=0
>
> Maven staging repo:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1092data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iMt9quMfvJoEjzEG6EaNo0Uux%2FDIf2G93aQz3b2VavI%3Dreserved=0
>
> GitHub:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mJPmmlAosWndYQUPmuPs7s%2F%2B%2FL5r74mz6IuqZmEdOvM%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MjjTdyVqUlM8A7fgt4riLuZE2eOrziuCUwvvsjbuMfQ%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=XZ7ukfiPnuAtmUdTyGBw%2FwfpZWR78imGuJUTfUrxQM4%3Dreserved=0
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.4.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290539316%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=IM6uq%2BxJqcwblYPx9aZ7W5SwEpzzdqHZNEYPMayQDtE%3Dreserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-maindata=04%7C01%7Cdasmith%40vmware.com%7Cefce038a1bbb481a0ff508d94d4851fa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637625795290549310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=zF%2BYeTbU5jMxSx7mYQh31c7JaQLVtcNm%2Fo5hfJPdKdk%3Dreserved=0
>
> 

Re: [VOTE] Apache Geode 1.13.3.RC1

[Dan Smith]

+1

-Dan

On Jun 21, 2021 2:23 PM, Nabarun Nag  wrote:
+1 based on the following:

  *   build from source
  *   running gfsh
  *   starting 2 site WAN cluster
  *   verifying data propagation from the 2 sites using puts and gets
  *   Rolling clusters from 1.12 to the release candidate.
  *   Rebalance operations during upgrades.

Regards,
Nabarun




From: Owen Nichols 
Sent: Monday, June 21, 2021 11:02 AM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.13.3.RC1

Hello Geode Dev Community,

I'd like to propose an expedited 1.13 patch release (24-hour voting deadline 
instead of 72).

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

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

Voting deadline:
3PM PDT Tue, June 22 2021.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.3data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252671128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6%2FTs%2BRDMxSQKSWqafmcQSHB4YOpEoI0RyX5nXPHhtzE%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.3.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252671128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=M1K2LK%2BW9h10wztP0PiyPoIgLb5ZQNTZ%2Fn8pMFlSJks%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1085data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252671128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H7vURIrWu19%2FmbnFl0iHjyVSQYjrrb3PV3ucqzUR9qo%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252681130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Lu4nomEGgQGnEuhVgIHyRu2mHQnSv2fHnYVKd7XTv%2B8%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252681130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VqT2PL%2BmExrVIyiM6NKZ%2F2QLFS0XH3IjEaMUXafTze0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252681130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dj7PoAj1MlYwRb%2FriaahgcaR%2FlWVhGOtldyaALqRK%2F0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.3.RC1data=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252681130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AtjE8lcpHETDOqBFTM2zXR5FSEAMJKLfVLGio2KBa%2F8%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252681130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WEIBNhYkyYiCMrCl7y0Viz8BQ3kEsgibKacy69%2FDM08%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Cdasmith%40vmware.com%7Cadc42de866ef4645609608d934fad8a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637599074252691124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=h%2FRs6NDMLXmI4T7WtN0MCOsHnK8lG18FijBRuxJxgsA%3Dreserved=0

Geode's KEYS file 

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

[Dan Smith]

I'm also -0 on this one. I personally kinda like having the merge button 
disabled on my PRs until all the checks are passing so I don't have to think as 
much, and I'm not sure this problem is going to come up again soon. But I'm 
willing go with disabling it.

-Dan

From: Mark Hanson 
Sent: Thursday, June 10, 2021 10:15 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

+1 to new report from Owen
+1 to re-introduce the stress-test

Great ideas Naba!

On 6/10/21, 9:50 AM, "Nabarun Nag"  wrote:

Hi all,


  *   We need to discuss how to prevent more flaky tests to be introduced 
now that stress-test is not mandatory for PRs to be merged? Reviewers checking 
the PR must check the tests failing in stress test and if it is a test that has 
been introduced or changed in the PR, the PR must be blocked with a change 
request or rejected.
  *   Also, in my opinion, we need to re-introduce the stress test as a 
mandatory check for PRs to be merged once the flaky test percentage has been 
reduced.

Owen, will it be possible to put out a list of all the flaky tests and we 
can try to get these resolved collectively as a community. (results of the mass 
tests maybe). Thank you.


Regards
Nabarun Nag

From: Kirk Lund 
Sent: Thursday, June 10, 2021 9:37 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

Ok, I wanted to give this discussion another night and we still have
consensus for making both stress-new-test non-required.

I just filed PR #6602 

 to change
stress-new-test from required to non-required. Please review!

On Wed, Jun 9, 2021 at 2:11 PM Anthony Baker  wrote:

> 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]?
> >
>
>

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

[Dan Smith]

Would it be possible to just split that test up into multiple classes? It 
sounds like the issue is that there is so many flaky tests in that class that 
you can't fix them all in one PR, which might indicate it's too big.

If we can't get StressNewTest to pass - that means our builds are failing more 
than 2% of the time due to this one test failure. Yikes!

-Dan

From: Kirk Lund 
Sent: Tuesday, June 8, 2021 9:33 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

Our requirement for stress-new-test-openjdk11 to pass before allowing merge
doesn't really work as intended for fixing distributed tests that contain
multiple flaky test methods. In fact, I think it causes contributors to
avoid tackling flaky tests.

I've been working on GEODE-9103: CI Failure:
PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED

 and was able to fix it.

However, stress-new-test-openjdk11 then continued to fail for other flaky
tests in PutAllClientServerDistributedTest. I managed to fix GEODE-9296 and
GEODE-8528 as well. I also tried but have not been able to fix GEODE-9242
which remains flaky.

Unfortunately, I cannot merge any of my fixes for
PutAllClientServerDistributedTest unless every single flaky test in it is
fixed by my PR. I think this is undesirable because it would be better to
merge the fix for 3 flaky test methods than none.

UPDATE: After running my precheckin more times, I did get
stress-new-test-openjdk11 to pass once so I can merge, but that's more of a
loophole than anything because I didn't manage to fix GEODE-9242.

Despite having PR #6542 eventually pass, I would like to discuss removing
or relaxing our requirement that stress-new-test-openjdk11 must pass in
order to merge a PR...

PR #6542: GEODE-9103: Fix ServerConnectivityExceptions in
PutAllClientServerDistributedTest


Fixed in PR #6542:
* GEODE-9296: CI Failure: PutAllClientServerDistributedTest >
testPartialKeyInPRSingleHopWithRedundancy

* GEODE-9103: CI Failure:
PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED

* GEODE-8528: PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop
fails due to missing disk store after server restart


Still flaky:
* GEODE-9242: CI failure in PutAllClientServerDistributedTest >
testEventIdOutOfOrderInPartitionRegionSingleHop


Thanks,
Kirk

Re: Stats deprecations?

[Dan Smith]

Looks like those methods were deprecated in GEODE-6850. If I'm reading that 
correctly, there is no reason not to change the calls to incLong, getLong, etc. 
I'd say go for it.

-Dan

From: Mark Hanson 
Sent: Wednesday, April 14, 2021 3:43 PM
To: dev@geode.apache.org 
Subject: Stats deprecations?

Hi,

So I am making some stats changes that are pretty minor, but I was looking at 
the fact that we have a ton of deprecated stuff about incInt and getInt. Can we 
convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: [DISCUSS] Monthly, synchronous community meetings

[Dan Smith]

Seems like a good idea. I have no preference on video conference platform.

-Dan

From: Alberto Gomez 
Sent: Friday, April 9, 2021 1:25 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Hi,

This idea sounds great to me.

Have you thought about the videoconference platform to host these meetings?

Best regards,

Alberto

From: Alexander Murmann 
Sent: Friday, April 9, 2021 2:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Monthly, synchronous community meetings

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

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

[Dan Smith]

Some apache projects have a "sandbox" repo or module. - Eg 
https://github.com/apache/solr-sandbox orhttps://commons.apache.org/sandbox.html

-Dan



From: Charlie Black 
Sent: Monday, March 29, 2021 12:14 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface

+ 1 to additional repos for extensions to Geode project to keep "extensions" or 
bolt-ons out of the Apache Geode.   I also have extensions that aren't 
committed to Geode.So definably a vibrant community surrounding Geode.

What todo with the code:  Just link to the branch/sha/fork/first addition to 
extensions/??? to the 2017 proposal.That would make finding the "source" 
and the design easier - 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FProtobuf%2BProtocoldata=04%7C01%7Cdasmith%40vmware.com%7C256303835d0f4565372408d8f2f541cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637526482478203218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aGmJQBPpeWpK5jbwS5wFF7OvqBLyEy4tbUELm0qRI7g%3Dreserved=0

Note:   Since this never got fully implemented - why is it in the implemented 
category.   Anyone with wiki access want to move it to "Unknown" since it is 
currently abandoned.

Charlie

On 3/29/21, 11:55 AM, "John Blum"  wrote:

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

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

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

$0.02
-j


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

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

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

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

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

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

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

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

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

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

--Jens

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

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

[Dan Smith]

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

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

-Dan

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

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

Mike


---
Sent from Workspace ONE 
Boxer

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

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

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

But I am just a single voice.

--Udo

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

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

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

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

-1

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

I don't know if I would go as far as removing this project/initiative out 
of Geode.
I understand that the way that was used to hook into Geode was less the 
perfect, and I fully support removing those and possibly replacing them with 
viable alternatives, if that makes the core Geode project better. What I don't 
support is the removal of the code completely on the basis that it isn't used 
by anyone (we have no proof either direction).

I think that the addition of this adapter is beneficial to the Geode. Given 
that lack of documentation relating to the Geode wire protocol, the barrier of 
entry for anyone else to connect to Geode is HUGE. The Protobuf initiative was 
the effort to lower the bar of entry for other
languages to be able to talk to Geode. But by removing it, we make Geode 
less accessible. I think the lack of focus on this effort can also attribute to 
the lack of use. As @Dave pointed 

Re: [Suspected Spam] RE: [VOTE] Apache Geode 1.13.2.RC1

[Dan Smith]

+1

Ran geode-release-check against this RC, looks good to me.

-Dan

From: Mark Hanson 
Sent: Tuesday, March 16, 2021 11:02 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] RE: [VOTE] Apache Geode 1.13.2.RC1

+1 for release.

Fixed a spelling error in release notes.
Tested release

Thanks,
Mark

On 3/16/21, 10:31 AM, "Dick Cavender"  wrote:

Please vote by 3pm today for 1.13.2. At this time we don't have enough 
votes to release although there are no -1s.

From: Dick Cavender
Sent: Thursday, March 11, 2021 1:34 PM
To: dev@geode.apache.org
Subject: [VOTE] Apache Geode 1.13.2.RC1

Hello Geode Dev Community,

It's been 4 months since the Apache Geode 1.13.1 release and there are a 
total 48 important fixes on support/1.13 that the community would benefit from. 
The recently released v1.12.1 has 33 

 fixes that are not released in 1.13. Based on this I propose release of an 
Apache Geode 1.13.2 based on the current support/1.13 branch. I'll volunteer to 
be the release manager for 1.13.2 and what follows is a release candidate for 
Apache Geode version 1.13.2.RC1.

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

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

Voting deadline:
3PM PST Tues, March 16, 2021

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

Release notes:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.2data=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696109343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=B5V2BscYY6TuAwltJoNox%2Flbq1rMcds%2FbCLYcTwDMIA%3Dreserved=0

Source and binary distributions:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.2.RC1%2Fdata=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696109343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pp%2BmtJLD6h8mFMnz580JLRk5P5OL5KMsE0ASQX5XyTo%3Dreserved=0

Maven staging repo:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1079data=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696109343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=duYPQWETi32IIbflXFKTv5eo%2FOPWiWmI8oQIsTB%2FcxM%3Dreserved=0

GitHub:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696109343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8pwl61np5akzNocxpqNaQWYOQPVUScF6trk6rGhGQPk%3Dreserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696119337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9gVK2OBke32PYQkoQ4lRS%2B4Fu2GOAjNtp2dDIElcdfg%3Dreserved=0

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.2.RC1data=04%7C01%7Cdasmith%40vmware.com%7C582d1be267254694fcde08d8e8a5b510%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637515145696119337%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=B7fnEiacCcKkY3kPf5ASbhOdhovUwQK8e2JDLPFAiV8%3Dreserved=0

Re: Cached regions are not synchronized after restore

[Dan Smith]

The java client at least should automatically drop its cache when it loses and 
restores connectivity to all the servers. See 
https://geode.apache.org/docs/guide/12/developing/events/how_client_server_distribution_works.html#how_client_server_distribution_works__section_928BB60066414BEB9FAA7FB3120334A3

-Dan


From: Jacob Barrett 
Sent: Friday, February 26, 2021 9:29 AM
To: dev@geode.apache.org 
Subject: Re: Cached regions are not synchronized after restore

For clarification, does the a Java client show the same behavior in missing the 
events after restore or is this something you are saying is unique to the 
native clients?

> On Feb 26, 2021, at 4:48 AM, Mario Salazar de Torres 
>  wrote:
>
> Hi,
> These months I have been tackling a series of issues having to do with 
> several inconsistencies in the geode-native client after a cluster restore.
> The later one has to do with subscription notification and cached regions. 
> The scenario is as follows:
>
>  1.  Start the cluster and the clients. For clarification purposes let's say 
> we have a NC and a Java client. Being the NC the local client, and Java 
> client the external one.
> Also note that NC client has subscription notification enabled for its pool 
> and the region has caching enabled.
>  2.  Register interest for all the region entries.
>  3.  Write some entries into the region from the Java client. Notifications 
> are received in the NC client and entries cached.
>  4.  Take a backup of the disk-stores.
>  5.  Write/modify some entries with the Java client. Notifications are 
> received in the NC client and entries cached.
>  6.  Restore the previous backup.
>  7.  Write/modify some entries with the Java client. Some of the 
> notifications are discarded and some others not.
> Note that all the entries which notifications were ignored did not exist in 
> the step 4 of the scenario.
>
> The reason why notifications mentioned in step 7 are ignored is due to the 
> following log:
> "Region::localUpdate: updateNoThrow for key [] failed 
> because the cache already contains an entry with higher version. The cache 
> listener will not be invoked"
>
> So, first of, I wanted to ask:
>
>  *   Any of you have encountered this issue before? How did you tackle it?
>  *   Is there any mechanism in the Java client to avoid this kind of issues 
> with caching de-sync? Note that I did not found any
>  *   Maybe we should add an option to clear local cached regions after 
> connection is lost towards the cluster in the same way is done with 
> PdxTypeRegistry?
>  *   Maybe any other solution having to do with cluster versioning?
>
> BR,
> Mario.

Re: [DISCUSS] client/server communications and versioning

[Dan Smith]

Ha, I was thinking of suggesting this when I saw Alberto's earlier proposal. 
This does seem like a good idea to only bump the client version when the 
protocol actually changes.

One concern is that it might not be obvious that changing a 
DataSerializableFixedId will change the client protocol. Some objects get sent 
or received from the client and some don't, but we don't have a clear 
indication which is which. Is there some way that we could know when changing a 
DataSerializableFixedId if it is involved in the client protocol or not?

I also wonder if this will affect the WAN - do we want to keep sending the 
current product version with the WAN, or use the client protocol version?

-Dan

From: Bruce Schuchardt 
Sent: Tuesday, February 23, 2021 9:38 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] client/server communications and versioning

I’m considering a change in client/server communications that I would like 
feedback on.

We haven’t changed on-wire client/server communications since v1.8 yet we tie 
these communications to the current version.  The support/1.14 branch 
identifies clients as needing v1.14 for serialization/deserialization, for 
instance, even though nothing has changed in years.

If we put out a patch release, say v1.12.1, clients running that patch version 
cannot communicate with servers running v1.12.0.  They also can’t communicate 
with a server running v1.13.0 because that server doesn’t know anything about 
v1.12.1 and will reject the client.  To solve that problem we currently have to 
issue a new 1.13 release that knows about v1.12.1 and users have to roll their 
servers to the new v1.13.1.

I propose to change this so that the client’s on-wire version is decoupled from 
the “current version”.  A client can be running v1.14.0 but could use v1.8.0 as 
its protocol version for communications.

This would have an impact on contributors to the project.  If you need to 
change the client/server protocol version you will need to modify 
KnownVersion.java to specify the change, and should let everyone know about the 
change.

See 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963data=04%7C01%7Cdasmith%40vmware.com%7C5b110c0f33d54702ebea08d8d821cfc1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637496987021268228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QplNcKl9wRM5R6RL9V2oLHUiYkur9214NcApA%2Bfhxfg%3Dreserved=0

Re: [Proposal] Geode Native Library Versioning

[Dan Smith]

ABI compatibility with the java layer has come up before [1]. At the time we 
decided to keep binary compatibility for the Java code.

That said, it's not common to break binary without breaking source 
compatibility in Java. C++ is a different animal, so I can see wanting to do 
something different there. I do think at least implementing some automated 
checking for whatever compatibility we intend to provide is a good idea.

[1] 
https://lists.apache.org/x/thread.html/ebdeabc24ce0ff418427021dfbbd45aceb51939f25de4aba7bb5c97b@%3Cdev.geode.apache.org%3E

From: Jacob Barrett 
Sent: Friday, January 29, 2021 12:00 PM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Geode Native Library Versioning

** sorry for the trashed formatting originally **

I would appreciate some feedback on this proposal by the end of day Friday, 
February 5th, 2021.

TLDR; The proposal is to formalize what has been effectively the status quo for 
Geode Native release in the current source form and any future binary form.



= The Problem =
Geode Native, specifically the C++ client, has a versioning problem. This is 
not a problem with compatibility or versioning between the Geode Native 
libraries and the Geode Server but rather an issue of compatibility between 
consumer applications and the Geode Native Libraries. Geode subscribes to the 
semantic version doctrine [1]. Semver describes API compatibility requirements 
but is largely silent on ABI, though it can be extended to the ABI. API and ABI 
compatibility are not the same thing. You can have an API compatible change 
that breaks the ABI and an ABI compatible change that breaks API. The 
intersection of the two creates even more complex rules around maintaining 
compatibility between release. All this in combination makes for really 
restrictive rules when trying to release even the smallest updates to a library.

For source releases this is really easy, you build what you need with your 
application and all should be happy. For binary releases this becomes a little 
harder. Since the consumer isn’t in control of what is built or how it is 
built, binary incompatibilities between releases can creep in. The difference 
is in the API vs ABI compatibility and while more pronounced in some languages 
it can exist in all. For example, one could create an ABI incompatibility in 
Java by compiling class files with a newer version of the runtime than the 
previous release. Those new classes, while API compatible, would not be 
loadable by the older runtime and classes thus making them ABI incompatible. In 
C++ not only does the runtime version play a role but the physical layout in 
memory, name mangle strategies, optimizations and other things can cause ABI 
incompatibility [2].

Geode Native has not maintained ABI compatibility between minor releases. Minor 
releases have included changes to exported types and methods changing. In the 
upcoming release of 1.14 there are a few incompatible changes around a new 
virtual method added to a base type. While the C++ language does not define how 
compilers and linkers should treat such changes they almost universally result 
in layout changes of the vtable and thus ABI incompatibilities.
The results of these incompatibilities at the ABI level are undefined and hard 
to diagnose. In a pinch if a consumer placed a patched library into their 
application that had an ABI compatibility issue it may appear to work but over 
time could exhibit odd behavior. Best case scenario it causes the application 
to exit but worst case it silently executes the wrong virtual methods resulting 
in the loss of data.


= ABI Versioning Options =
We must communicate ABI versioning to consumers of the library. Before we can 
do that we must decide on ABI versioning rules.

== Semantic Versioning for ABI ==
This is probably the most restrictive of our options. If the ABI is included in 
semantic versioning then no changes can be made to types with virtual methods. 
For example, the recent change to add expected domain names to PDX types would 
not have been possible until a major release. This change resulted in the 
change to a base type virtual method, thus a vtable change and an ABI 
incompatible change. The benefit to consumers is that they never need to 
recompile their applications for minor or patch updates unless taking advantage 
of non-breaking API compatible changes.

== No ABI Versioning ==
If ABI is not considered as part of the semantic versioning scheme then every 
release expects a complete recompile from all applications. This is an easy 
rule for consumers to follow but isn’t ideal for minor patches where it is 
likely a drop in binary could be possible and certainly less disruptive than a 
full recompile.

== Hybrid Semantic Versioning ==
We could communicate some custom rule where only patch level semantic versioned 
releases are ABI compatible and any major or minor release requires a 
recompile. I believe we 

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

[Dan Smith]

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 
Sent: Friday, January 29, 2021 11:40 AM
To: 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 
Sent: Friday, January 29, 2021 1:56 AM
To: 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.

-Dan

From: Alberto Gomez 
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Hi,

I have updated the proposal in the RFC by adding Patrick's suggestion (if I 
have understood it correctly).

Best regards,

Alberto

From: Alberto Gomez 
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Thanks for your comments, Patrick.

Do you mean have the client always use in the handshake the oldest server 
version it is compatible with?

Sounds like a reasonable simplification. In that case, I would use a flag to 
activate this behavior so that the current behavior (the client sends the 
current version in the handshake) is kept when the flag is not used.

On the other hand if in the future we have clients that are partially 
compatible with an older server version, the System Property with the version 
could allow these clients to connect to that server version assuming that they 
will not use any incompatible feature.

Alberto



From: Patrick Johnson 
Sent: Friday

Re: Inputs for efficient querying

[Dan Smith]

For the best performance, you should store column2 as a java Map instead of a 
String which contains a json document. If column2 was Map, you 
could do a query like this:


SELECT * FROM /exampleRegion r WHERE r.column2['k1'] IN SET('v10', 'v15', 'v7')"

You can create an index on the map to optimize this sort of query

gfsh>create index --name="IndexName" --expression="r.column2[*]" 
--region="/exampleRegion r"

This page might be helpful

https://geode.apache.org/docs/guide/112/developing/query_index/creating_map_indexes.html

In addition, I noticed that your value implements Serializable. You will get 
better performance out of the query engine if you configure PDX serialization 
for your object, either by configuring the auto serializer or implementing 
PdxSerializable. That avoids the need to deserialize your entire value on the 
server to query/index it.

-Dan



From: ankit Soni 
Sent: Friday, January 29, 2021 9:32 AM
To: dev@geode.apache.org 
Subject: Inputs for efficient querying

Hello Team,

I am loading data into Geode (V 1.12) with the following *Key (of type
String)* and *value (custom java object - ValueObject)*.

*public class ValueObject implements Serializable {*
* private int id;*

* private String keyColumn;   <- Region.Key *

* private String column_2; <-- Json document*
* private String column_3;*

* private String column_4*



* //few more string type members*
*}*

*Keycolum* is a normal string of around 8 chars, like "12345678",
"23456789" etc...

*In ValueObject, column_2 is of type string and having a values of type
valid JSON doc as bellow; *
{"k1" : "v1", "k3" : "v3", "k6" : "v6", "k7" : "v7", *"k10" : "v7"*, "k12"
: "v12", "k13" : "v13"}
{"k2" : "v2", "k3" : "v3", "k4" : "v4", "k6" : "v6", *"k10" : "v10"*, "k13"
: "v13", "k14" : "v14"}
{"k1" : "v1", "k2" : "v2", "k6" : "v6", "k8" : "v8", "k10" : "v7", "k12" :
"v12", "k13" : "v13", "k14" : "v14"}
.

after storing the data in Geode i need to run following two queries.
*Query to be supported.*


*Q1. //query with filter on keyColumn*
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION.keyset key
where (key IN SET('12345678', '23456789', '34567890'))"


*Q2. //query with filter on column_2 attribute, something like "where
d.column_2.k10 IN SET('v10', 'v15', 'v7'); *
"select d.keyColumn, d.column_2, d.column_3, d.column_4
from /DATA_REGION v
where v.column_2.k10 INSET('v10', 'v15', 'v7')"

I am able to run the Q1 but not sure *how to achieve Q2 (form a OQL for
this case)*...?

Request team to help, how can i efficiently form and execute above kind of
queries with geode OQL...?

Also advise, what kind of index are recommended to get higher query
performance for above queries...?

Thanks
Ankit.

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

[Dan Smith]

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.

-Dan

From: Alberto Gomez 
Sent: Tuesday, January 26, 2021 6:45 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Hi,

I have updated the proposal in the RFC by adding Patrick's suggestion (if I 
have understood it correctly).

Best regards,

Alberto

From: Alberto Gomez 
Sent: Friday, January 22, 2021 10:41 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

Thanks for your comments, Patrick.

Do you mean have the client always use in the handshake the oldest server 
version it is compatible with?

Sounds like a reasonable simplification. In that case, I would use a flag to 
activate this behavior so that the current behavior (the client sends the 
current version in the handshake) is kept when the flag is not used.

On the other hand if in the future we have clients that are partially 
compatible with an older server version, the System Property with the version 
could allow these clients to connect to that server version assuming that they 
will not use any incompatible feature.

Alberto



From: Patrick Johnson 
Sent: Friday, January 22, 2021 8:35 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect 
to older Geode servers

It sounds like you intend to test which versions are compatible with each other 
and maintain a list the client can use to reject the setting of force-version 
when set to an incompatible version. If that’s the case, why not just have the 
handshake look at that list and automatically connect with any versions that it 
is known to be compatible with? Then you wouldn’t even have to set the property.

> On Jan 22, 2021, at 11:05 AM, Alberto Gomez  wrote:
>
> Hi Geode devs,
>
> I have just published the following RFC in the Geode wiki: "Add option to 
> allow newer Geode clients to connect to older Geode servers"
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAdd%2Boption%2Bto%2Ballow%2Bnewer%2BGeode%2Bclients%2Bto%2Bconnect%2Bto%2Bolder%2BGeode%2Bserversdata=04%7C01%7Cdasmith%40vmware.com%7C776eddfeec43423ccfee08d8c2091d4d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637472691702967826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jRf5gJ7UIlCnrK%2FLfH6fSg1yLtb3%2BMdc3krwkOvtJA0%3Dreserved=0
>
> Could you please provide feedback by Tuesday, February 2nd, 2021?
>
> Thanks,
>
> Alberto G.
>

Re: Different binding addresses for traffic & membership

[Dan Smith]

I've been looking into the code a little bit to see if this is possible. I'm 
not sure it is right now.

Here's some pointers at where to look at. Most of the magic is happening in 
JGroupsMessenger. JGroupsMessenger wraps jgroups, which we are using to UDP 
messaging related to membership.

The first thing that happens is that JGroupsMessenger.init creates a jgroups 
configuration. It does some string replacement on the jgroups-config.xml file 
that is checked. It puts the configured bind-address into that configuration.

When JGroupsMessenger.start() is called jgroups will bind to that address. 
Right after that, JGroupsMessenger calls establishLocalAddress, which takes the 
IP address that jgroups just bound to and creates our local MemberIdentifier.

Later in GMSJoinLeave.attemptToJoin, it sends that local address to the 
coordinator. Assuming the join is successful, the coordinator will send out a 
view that includes that MemberIdentifier.


I was really hoping that just setting a bind address of "0.0.0.0" would do the 
right thing in this case. But it looks like jgroups won't let you bind to that 
address. I don't currently see a way to get a different address in the 
MemberIdentifier than the one that jgroups is listening on right now.

Besides the UDP port that jgroups is listening on, there are a couple of other 
TCP ports used for peer-to-peer messaging. GMSHealthMonitor also starts 
listening on the same local address returned from jgroups. And the 
DirectChannel class I think also eventually ends up creating a server socket 
that listens on the same bind-address. That one might be ok with "0.0.0.0".

-Dan

PS - there is a lot more information on membership on the wiki if it is 
helpful, but I don't think it gets into this level of detail about what address 
gets used - 
https://cwiki.apache.org/confluence/display/GEODE/Membership+Manager+and+Messaging.



From: Aaron Lindsey 
Sent: Wednesday, January 20, 2021 2:51 PM
To: dev@geode.apache.org 
Subject: Re: Different binding addresses for traffic & membership

> Is there any way to configure a bind address to be used only for membership?

To your first question, I asked around but I’m not aware of anything like what 
you are looking for. What you are describing does seem like it could become a 
common setup on Kubernetes, but I personally haven’t tried using Geode with 
Istio and Envoy. Please share what you learn!

> I thought that it will be interesting to take a look at how the membership 
> works (how the distributed system is created), to check if at some point I 
> could decouple how the value of "bind-address" parameter is used to configure 
> binding and to indicate other members that they can reach the new member at 
> that hostname. Any comment about what I should check first is welcome.

Maybe someone with more experience in the membership code could comment on this?

Aaron

> On Jan 20, 2021, at 9:07 AM, Alberto Bustamante Reyes 
>  wrote:
>
> It seems this is not a trendic topic...  Let me share my approach by the 
> moment, maybe this will receive more comments:
>
> I thought that it will be interesting to take a look at how the membership 
> works (how the distributed system is created), to check if at some point I 
> could decouple how the value of "bind-address" parameter is used to configure 
> binding and to indicate other members that they can reach the new member at 
> that hostname. Any comment about what I should check first is welcome.
>
> Thanks!
>
> BR/
>
> Alberto Bustamante
>
>
>
>
>
> 
> De: Alberto Bustamante Reyes 
> Enviado: martes, 19 de enero de 2021 1:45
> Para: dev@geode.apache.org 
> Asunto: Different binding addresses for traffic & membership
>
> Hi geode-devs,
>
> I have a question related with Geode & Kubernetes:
> We would like to use Istio with Geode. For that, a sidecar container (Envoy) 
> has to be added in each Geode pod. That sidecar container intercepts and 
> handles all incoming and outgoing traffic for that pod. One of the 
> requirements set by Istio towards applications trying to integrate with it is 
> that the application listening ports need to be bound to either localhost or 
> 0.0.0.0 address (which listens on all interfaces).
>
> Geode binds the locator and server traffic port by default to 0.0.0.0, but 
> the membership ports are bound to the pod IP.
> And with Envoy listening on the pod IP for incoming traffic and proxying 
> everything towards localhost, applications binding to pod IPs won't receive 
> any traffic.
>
> We have tried using the "bind-address" parameter, but that doesn't work for 
> our case. Geode binds the listening ports to the configured address, but it 
> also shares that same address to other members in the system as the address 
> to be used to reach it. If we configure that address to localhost, it just 
> won't work.
>
> Is there any way to configure a bind address to be used only for membership? 

Re: Request for rights to write comments on Apache Geode Confluence

[Dan Smith]

Done. You should have access now.

Thanks!
-Dan

From: Jakov Varenina 
Sent: Monday, January 11, 2021 2:09 AM
To: dev@geode.apache.org 
Subject: Request for rights to write comments on Apache Geode Confluence

Hi devs,

Could you please give me rights to write comments on Apache Geode
Confluence page?

username: jakov.varenina

BRs,

Jakov

Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

[Dan Smith]

Hi Owen,

Thanks for pushing this forward! Given that a lot of folks are on holiday - 
maybe sometime in January might be a better time to merge this to develop to 
give everyone a chance to look at it? How about Jan 8th?

I'm glad you nominated some folks to be owners by filling them in. I don't 
think we should make anyone an owner unless they positively accept though. Can 
we agree to remove nominees that don't accept before merging? Similarly, I 
think if some areas don't get more than one owner they should just be left 
unowned.

-Dan

From: Owen Nichols 
Sent: Tuesday, December 15, 2020 3:00 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode

Given the support this is receiving, it looks like the next step is to bring 
CODEOWNERS to develop.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5855data=04%7C01%7Cdasmith%40vmware.com%7C4c8d3115c3b84a549d9008d8a14d8d18%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637436701775178422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZD9bdTuaRwEybrmKMBuV7jXpBvfjBFv%2FHzYCSoUwpL0%3Dreserved=0
 has been created to merge the CODEOWNERS file to develop.  I filled in a few 
gaps based on commit history for those areas…if so I’ve tagged you and/or added 
you as a reviewer.  If you are in any way not comfortable please -1 and/or push 
changes directly to this PR branch.  Let’s keep this PR open for another week 
to allow time for everyone to see it and raise any concerns, and plan to merge 
to develop on Dec 22.

From: Jens Deppe 
Date: Monday, December 14, 2020 at 7:25 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
I've self-nominated for redis, management and security.

--Jens

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

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

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

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

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

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

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

-Robert

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

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

--Jens

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

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




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

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

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5802data=04%7C01%7Cdasmith%40vmware.com%7C4c8d3115c3b84a549d9008d8a14d8d18%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637436701775178422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=saDW8pnnpI8JbO2A%2FOdv4vH6xOUtHxyyJ7cBseK%2Bdz8%3Dreserved=0

From: 

Re: [Proposal] - Cleanup Protocol Version Checks

[Dan Smith]

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

BTW, I don't think a vote is necessary. If you don't get objections by 12/18 I 
think you can just move forward.

-Dan

From: Dan Smith 
Sent: Wednesday, December 9, 2020 11:16 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] - Cleanup Protocol Version Checks

+1 to rejecting clients (and WAN sites) with versions less than 
KnownVersion.GFE_82, and obsolete compatibility code.

-Dan

From: Jacob Barrett 
Sent: Wednesday, December 9, 2020 9:35 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] - Cleanup Protocol Version Checks



> On Dec 9, 2020, at 8:09 AM, Bruce Schuchardt  wrote:
>
> We should also get rid of the old jump tables in CommandInitializer

Would it make sense to do that in the same PR that tackles setting the min 
client version in the handshake or should that be a separate task?

-Jake

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

[Dan Smith]

I will go ahead and withdraw my objection to this change. Based on some side 
conversations, at least at VMWare it sounds like we don't have customers that 
are not setting this flag. So the scenario I'm worried about where a customer 
upgrades their production cluster and has it crash due to this change seems 
less likely. I do agree false is a better default.

I would also be fine waiting until 2.0 to make this change.

-Dan

Re: [Proposal] - Cleanup Protocol Version Checks

[Dan Smith]

+1 to rejecting clients (and WAN sites) with versions less than 
KnownVersion.GFE_82, and obsolete compatibility code.

-Dan

From: Jacob Barrett 
Sent: Wednesday, December 9, 2020 9:35 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] - Cleanup Protocol Version Checks



> On Dec 9, 2020, at 8:09 AM, Bruce Schuchardt  wrote:
>
> We should also get rid of the old jump tables in CommandInitializer

Would it make sense to do that in the same PR that tackles setting the min 
client version in the handshake or should that be a separate task?

-Jake

Concourse TLS cert has expired

[Dan Smith]

If I go to https://concourse.apachegeode-ci.info/ I get this error - who can 
fix this?

The certificate for concourse.apachegeode-ci.info expired on 12/2/2020.

-Dan

[DISCUSS] - Use Java 11 for geode-examples

[Dan Smith]

A contributor submitted a PR[1] to our geode examples project that uses Java 11 
APIs. It doesn't pass travis because we're still building the examples with 
Java 8.

I think it might be reasonable to switch the minimum java version of the 
examples to Java 11. If there are no objections, I'll go ahead and create a PR 
to switch the java version we use to build the examples.

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

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

[Dan Smith]

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: Request for Jira Permissions

[Dan Smith]

Done. You should have access now.

-Dan

From: John Hutchison 
Sent: Wednesday, November 18, 2020 11:00 AM
To: dev@geode.apache.org 
Subject: Request for Jira Permissions

Hi,

I’d like to request permission to assign jira tickets to myself and also to 
reopen tickets that have been resolved.

Thanks,
John

Re: [VOTE] Apache Geode 1.13.1.RC2

[Dan Smith]

+1

Looks good to me! I ran the geode-release-check against it, looked for binary 
artifacts, checked the pipeline.

-Dan

From: Dick Cavender 
Sent: Thursday, November 12, 2020 5:00 PM
To: dev@geode.apache.org 
Subject: [VOTE] Apache Geode 1.13.1.RC2

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.13.1.RC2.
Issues with creation of RC1 forced moving to RC2.
Thanks to all the community members for their contributions to this release!

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

Voting deadline:
3PM PST Tue, November 17 2020.

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

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.13.1data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4vRYefr%2Bx9Lz18%2BZFO3x%2FSYMdz8%2B%2FCSccrXiuSPiGt8%3Dreserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.13.1.RC2%2Fdata=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=N9mFEBqWyWqp8CI9zI9KX831oMzPQnJGWuTMuORG964%3Dreserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1071data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=O36mwKeH8GDQhpShsTVkK%2B3GYt5gJC1cuLg8fHQzyQY%3Dreserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2Fy%2BxHFK%2BDPWRp1k10fpdnJjXFg5W%2F8pOoFq6viPUFT8%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=y4eQqpwIIgpmdRsKb%2FqBWIM7eLZ9d0PBwi0bf%2BxfNvg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404370999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zqt9W4tOlg23Yjv%2FPsz%2FrKOIq%2BK%2FRkbgd7tY%2BUcgG3s%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.13.1.RC2data=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404380998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PycDQbMPFNz4JOVAHu7g0U2NFjZdyc6II2kU52%2BWaPE%3Dreserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-maindata=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404380998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SubE%2Fnkqr2Qkzagg%2FB5CkSwoH3f6aLTSDWwcCHp9xbY%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-rcdata=04%7C01%7Cdasmith%40vmware.com%7Cd50c5cb12cba485293d708d8876f8993%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637408260404380998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=T6Bh3LoGelScH9mrjpybv9%2FdFNgzX6IvQwY%2FHJ0TyXo%3Dreserved=0

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

Re: Apache Geode 1.13.1 patch proposal

[Dan Smith]

+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