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

[Jakov Varenina]

Hi Dan,

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


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


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

BRs/Jakov


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


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


-Dan

*From:* Jakov Varenina 
*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.




Sorry for any inconvenience.

BRs/Jakov


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


Hi Dan,


Thank you for your answer!


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




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





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



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



https://github.com/apache/geode/pull/7145 




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  


*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 (drfOnlyOplo

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

[Mario Salazar de Torres]

Hi Dan,

It's clear that supporting this case is tricky, both technically and in terms 
of security. However, luckily that's not the goal here.
Thing is what we've observed is during some scenario (probably while using a 
proxy, like envoy), the client receives a response from locators which is not 
expecting.
In the case of Java, the answer to VersionRequest is not a VersionResponse, 
which in the end seems to terminate the calling thread (quite concerning as the 
client could continue while several background tasks are stopped).
In the case of geode-native if the first byte from the locator response is 21, 
then it considers that the locator has SSL enabled and if the client has not 
SSL configured then it exits.

Thing is we are considering in changing this behavior, as at least for Java 
client, as just terminating the thread is quite concerning. So, do you happen 
to know why this logic was implemented?
I think it's quite important to have that kind of insight before considering a 
change.

Thanks!
Mario.

From: Dan Smith 
Sent: Wednesday, December 1, 2021 11:28 PM
To: dev@geode.apache.org 
Subject: Re: Client terminating when trying to connect to an SSL configured 
locator

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%23L147&data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373842079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q%2F18j0f3GtCXUS5jtI8fZbdjUFn7ouRwRd%2BnAKFA9QY%3D&reserved=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%23L278&data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373852076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZkixzNe4sGUzIQOz%2FNc1gdYBI%2B6F%2FFeG2HsPf3ZaYVU%3D&reserved=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

[Anthony Baker]

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

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

Hi Dan,

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

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

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

BRs/Jakov


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

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

-Dan

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

Hi Dan and all,


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



Sorry for any inconvenience.

BRs/Jakov


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

Hi Dan,


Thank you for your answer!


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



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




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


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


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7145&data=04%7C01%7Cbakera%40vmware.com%7Cbd2758bd10a54592fcef08d9b573cebe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740331264764503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ua49Y%2F4PwKhQHHgz898uxDLde%2BZpZZFxMBY%2FgIL8%2BEE%3D&reserved=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 
th

Apache Geode Community Meeting

[Alexander Murmann]

Hi everyone,

Sorry, I didn't organize the December community meeting that should have taken 
place today. Given, it's the holiday season coming up, I wonder if it makes 
sense to not bother rescheduling and instead start looking at our January 
meeting.

Does anyone have a topic they'd like to present or discuss on January 6th?

Re: [DISCUSS] batch patch release voting

[Robert Houghton]

In the case where its one change being backported all over, I say batch up the 
vote.

From: Owen Nichols 
Date: Wednesday, December 1, 2021 at 11:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting
Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

RE: [DISCUSS] batch patch release voting

[Dick Cavender]

+1 for batching them. 

Is it implied with a +1 vote that all the releases have been checked or can you 
only vote on a single release if that's all you checked? We can define this 
when we send out the vote email. 

-Original Message-
From: Robert Houghton  
Sent: Thursday, December 2, 2021 11:26 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSS] batch patch release voting

In the case where its one change being backported all over, I say batch up the 
vote.

From: Owen Nichols 
Date: Wednesday, December 1, 2021 at 11:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting Geode's N-2 support policy can 
lead to "waves" of patch releases.  For example, 1.12.6, 1.13.5 and 1.14.1 are 
all likely this month, with many of the same fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: [DISCUSS] batch patch release voting

[Donal Evans]

The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Temporary Instability

[Sean Goller]

Due to some memory pressure we need to increase the size of some nodes in
the ci infrastructure. Due to this there may be some instability with
concourse, but we don't believe there will be any. This is just a heads up
in case something happens.

-Sean.

Re: [DISCUSS] batch patch release voting

[Robert Houghton]

I would hope that all RCs had been checked thoroughly before any release VOTE 
occurs.

From: Donal Evans 
Date: Thursday, December 2, 2021 at 11:47 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: Temporary Instability

[Sean Goller]

The upgrade is complete, so everything should be working normally.

On Thu, Dec 2, 2021 at 2:05 PM Sean Goller  wrote:

> Due to some memory pressure we need to increase the size of some nodes in
> the ci infrastructure. Due to this there may be some instability with
> concourse, but we don't believe there will be any. This is just a heads up
> in case something happens.
>
> -Sean.
>

Re: [DISCUSS] batch patch release voting

[Owen Nichols]

It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE Boxer

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: [DISCUSS] batch patch release voting

[Udo Kohlmeyer]

I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: [DISCUSS] batch patch release voting

[Owen Nichols]

I wonder if voting on patch versions makes sense.


Releasing (even patch releases) is an Act of the Apache Software Foundation, 
and as such there is a legal obligation to follow ASF voting rules for every 
release. Technically the purpose of the vote is for the Geode PMC to certify 
that the release meets ASF legal criteria (but there’s never such thing as too 
much testing, so we also hope reviewers will use the opportunity to think up 
creative new ways to test each release candidate)

---
Sent from Workspace ONE Boxer

On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer  wrote:
I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: [DISCUSS] batch patch release voting

[Udo Kohlmeyer]

I thought that was the case…

Then maybe every release has to be voted on, no bulk/batch allowed, as every 
release has to be verified separately.

Which, just means that bulk announcements is the only thing that makes sense…

From: Owen Nichols 
Date: Friday, December 3, 2021 at 10:39 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
I wonder if voting on patch versions makes sense.


Releasing (even patch releases) is an Act of the Apache Software Foundation, 
and as such there is a legal obligation to follow ASF voting rules for every 
release. Technically the purpose of the vote is for the Geode PMC to certify 
that the release meets ASF legal criteria (but there’s never such thing as too 
much testing, so we also hope reviewers will use the opportunity to think up 
creative new ways to test each release candidate)

---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer  wrote:
I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: [DISCUSS] batch patch release voting

[Owen Nichols]

We already do “bulk/batch” release voting, as every vote covers several 
artifacts (geode, geode-native, geode-benchmarks, geode-examples).  I don’t 
interpret the ASF rules as setting any limit on the number of artifacts that 
can be approved in one vote.

It sounds like the rough consensus from this thread is to continue with 
separate votes per patch release, and just combine the announcement.  Thanks 
all for the input.



---
Sent from Workspace ONE Boxer

On December 2, 2021 at 4:27:05 PM PST, Udo Kohlmeyer  wrote:
I thought that was the case…

Then maybe every release has to be voted on, no bulk/batch allowed, as every 
release has to be verified separately.

Which, just means that bulk announcements is the only thing that makes sense…

From: Owen Nichols 
Date: Friday, December 3, 2021 at 10:39 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
I wonder if voting on patch versions makes sense.


Releasing (even patch releases) is an Act of the Apache Software Foundation, 
and as such there is a legal obligation to follow ASF voting rules for every 
release. Technically the purpose of the vote is for the Geode PMC to certify 
that the release meets ASF legal criteria (but there’s never such thing as too 
much testing, so we also hope reviewers will use the opportunity to think up 
creative new ways to test each release candidate)

---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer  wrote:
I wonder if voting on patch versions makes sense. As we should never be 
breaking any existing features and essentially there should be sufficient 
testing on the fixes to confirm that they resolve the issues. There should also 
be no changes to APIs, as those changes should be included in a new minor.

I think a bulk announcement makes sense… So where possible we should/could 
adopt that approach.

But bulk vote for releases does not, as each patch version might contain 
different amount of fixes, for each minor. (some fixes might only be required 
in older/newer minor versions)

From: Owen Nichols 
Date: Friday, December 3, 2021 at 9:56 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] batch patch release voting
It doesn’t really make a lot of sense to release a fix in a 1.12 patch 
separately without later patches. Doing so would send the confusing message 
that users need to downgrade to get the fix (or if they upgrade they will lose 
it).

So, whether we vote separately or not, we should still probably wait to 
announce all together once all three are ready.


---
Sent from Workspace ONE 
Boxer

On December 2, 2021 at 11:47:28 AM PST, Donal Evans  wrote:
The thing I wonder about with this decision is what happens if there are no 
problems with two of the releases, but one of them has some showstopping issue 
that needs to be addressed.

Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's 
possible that an unrelated issue with the 1.14 patch release could hold up the 
release of the perfectly fine 1.12 release if the vote is on releasing all 
three. In that case, would there need to be a new RC for the 1.12 and 1.13 
releases, given that the vote for them would technically have failed? Would 
there need to be a new vote on all three releases, or just go ahead with the 
1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed?

From: Owen Nichols 
Sent: Wednesday, December 1, 2021 11:45 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] batch patch release voting

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?