geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: [DISCUSS] Release Geode 1.9.1 with logging improvements
Date Wed, 28 Aug 2019 20:38:09 GMT
The VOTE for 1.9.1.RC1 failed due to lack of quorum, so re-opening this thread to continue
the discussion.

Is there still a need for a 1.9 patch release (especially given that 1.10.0.RC1 is expected
later this week)?

If so, perhaps we should back up a step or two and first:
1) come to rough consensus that 1.9.1 is still desired (and what should be in it)
2) ensure that we have Geode PMC support for this release
3) go through the formal process of voting each cherry-pick in the patch release

This could result in a recommendation to re-vote on RC1, a recommendation to produce a new
RC2, a recommendation to pull the plug (or no recommendation).

As a failsafe, I hereby invoke lazy consensus: In the event that no explicit decision to move
forward with 1.9.1 is reached by 3pm PDT Wed Sep 4, I will dismantle the current 1.9.1 branch,
pipeline and nexus staging repo and remove 1.9.1 from the release notes wiki.

-Owen


> On Aug 18, 2019, at 7:52 AM, Anthony Baker <abaker@pivotal.io> wrote:
> 
> Yep. Get a release manager, identify and cherry pick all the changes, then do the release.

> 
> Anthony
> 
>> On Aug 16, 2019, at 4:21 PM, Kirk Lund <klund@apache.org> wrote:
>> 
>> Does anyone know what the next step is? Do we need a release manager to
>> proceed?
>> 
>>> On Tue, Aug 13, 2019 at 1:57 PM John Blum <jblum@pivotal.io> wrote:
>>> 
>>> Sorry, corrections below...
>>> 
>>>> On Tue, Aug 13, 2019 at 1:54 PM John Blum <jblum@pivotal.io> wrote:
>>>> 
>>>> Stated slightly a different way...
>>>> 
>>>> If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then
>>>> it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2
>>>> (which is and can only be Geode 1.9 *at this point*) for which SBDG is
>>>> also based, along with Spring Boot 2.2, which pulls in SD Moore/2.2 and
>>>> therefore Geode 1.9, *indirectly (i.e. transitively)*, as well.  As such,
>>>> the stars would not align and it would cause issues (or unexpected
>>>> surprises, possibly conflicts) for users of Spring Boot when also using
>>>> SBDG.  *With**out* SBDG, users of Spring Boot would get Geode 1.9 due to
>>>> the SD Moore/2.2 dependency, but with SBDG on the classpath, it would
>>>> suddenly (possibly) change the Geode version to 1.10.  That is
>>> definitively
>>>> bad.
>>>> 
>>>> Therefore, SBDG 1.2 based on Boot 2.2, Data 2.2 will get Geode 1.9.
>>>> 
>>>> SBDG 1.3 will be based on Boot 2.3 (not available), Data 2.3 (not
>>>> available) which will pull in the latest version of Geode at that time
>>>> (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC
>>>> status.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Tue, Aug 13, 2019 at 1:45 PM John Blum <jblum@pivotal.io> wrote:
>>>>> 
>>>>> For clarification...
>>>>> 
>>>>> 1. SBDG 1.1 is the "*current*" development line (on
>>>>> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
>>>> 
>>>>> master
>>>>> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17>
>>> [1]);
>>>>> SBDG 1.2 is *not* yet in development.
>>>>> 2. SBDG 1.1 is at RC1
>>>>> <https://github.com/spring-projects/spring-boot-data-geode/releases>
>>> [2].
>>>>> 3. SBDG 1.1 is based on Spring Boot 2.1
>>>>> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8>
>>> [3]
>>>>> and Spring Data (Geode) Lovelace
>>>>> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12>
>>> [4]
>>>>> (or SDG 2.1
>>>>> <
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10>
>>> [5]);
>>>>> This is not arbitrary because all the stars (bits, transitive dependency
>>>>> versions) must "align" as defined by what Spring Boot 2.1 declares, and
>>>>> Spring Boot 2.1 is based on
>>>>> <
>>> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169>
>>> [6]
>>>>> Spring Data Lovelace/2.1.
>>>>> 4. Spring Data Geode (SDG) Lovelace/2.1 is based on
>>>>> <
>>> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25>
>>> [7]
>>>>> Apache Geode 1.6.
>>>>> 5. All SDG Lovelace/2.1.x versions will always be based on the latest
>>>>> Apache Geode 1.6.x anything (currently, 1.6.0) until the rest of time.
>>>>> This ship has sailed.
>>>>> 
>>>>> ~~~~
>>>>> 
>>>>> 6. SBDG 1.2, when it reaches development (soon),will be based on Spring
>>>>> Boot 2.2
>>>>> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8>
>>> [8],
>>>>> Spring Data (Geode) Moore
>>>>> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12>
>>> [9]
>>>>> (or SDG 2.2
>>>>> <
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10>
>>> [10]);
>>>>> This is also not arbitrary because Spring Boot 2.2 declares a dependency
>>>>> on
>>>>> <
>>> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185>
>>> [11]
>>>>> Spring Data Moore.  Again, the stars must align.
>>>>> 7. Spring Data Geode (SDG) Moore/2.2 is based on
>>>>> <
>>> https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25>
>>> [12]
>>>>> Apache Geode 1.9.0.
>>>>> 8. As you can see, SDG Moore/2.2 is already in release candidates (i.e.
>>>>> RC2 or the 2nd release candidate), which means SDG cannot be rebased
on
>>>>> 1.10 at this point.  The transitive dependency major.minor versions are
>>> now
>>>>> fixed for SD(G) Moore/2.2.
>>>>> 9. SDG Moore/2.2 can pick up any version of Apache Geode 1.9.x (e.g.
>>>>> 1.9.1 up to  1.9.N where N is 0... infinity).
>>>>> 
>>>>> Finally, SDG's next opportunity to pick up Apache Geode 1.10 or 1.11
or
>>>>> 1.whatever is in the next SD Release Trains, Neuman, or 2.3.  SDG can
>>>>> continue to pick up new versions of Apache Geode 1.10, 1.11, 1.12, etc
>>>>> until SDG Neuman/2.3 reaches it's first release candidate (RC) release,
>>> at
>>>>> which point the major.minor becomes fixed in that particular SD Release
>>>>> Train, until the next SD Release Train (Neuman.next).
>>>>> 
>>>>> Make sense?
>>>>> 
>>>>> So, it is the SDG version (along with Spring Boot core) that SBDG
>>> depends
>>>>> on that determines the version of Apache Geode that SBDG pulls in.
>>>>> 
>>>>> Hope this helps!
>>>>> 
>>>>> Regards,
>>>>> John
>>>>> 
>>>>> 
>>>>> [1]
>>>>> 
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/master/gradle.properties#L17
>>>>> [2] https://github.com/spring-projects/spring-boot-data-geode/releases
>>>>> [3]
>>>>> 
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L8
>>>>> [4]
>>>>> 
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L12
>>>>> [5]
>>>>> 
>>> https://github.com/spring-projects/spring-boot-data-geode/blob/1.1.0.RC1/gradle.properties#L10
>>>>> [6]
>>>>> 
>>> https://github.com/spring-projects/spring-boot/blob/v2.1.7.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L169
>>>>> [7]
>>>>> 
>>> https://github.com/spring-projects/spring-data-geode/blob/2.1.10.RELEASE/pom.xml#L25
>>>>> [8]
>>>>> 
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L8
>>>>> [9]
>>>>> 
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L12
>>>>> [10]
>>>>> 
>>> https://github.com/jxblum/spring-boot-data-geode/blob/1.2.x/gradle.properties#L10
>>>>> [11]
>>>>> 
>>> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M5/spring-boot-project/spring-boot-dependencies/pom.xml#L185
>>>>> [12]
>>>>> 
>>> https://github.com/spring-projects/spring-data-geode/blob/2.2.0.RC2/pom.xml#L25
>>>>> 
>>>>> 
>>>>> On Tue, Aug 13, 2019 at 12:40 PM Aaron Lindsey <alindsey@pivotal.io>
>>>>> wrote:
>>>>> 
>>>>>> Thanks, Udo.
>>>>>> 
>>>>>> +1 for doing a 1.9.1 patch release, assuming there is enough time
for
>>>>>> SBDG to include it in their 1.2.x line.
>>>>>> 
>>>>>> - Aaron
>>>>>> 
>>>>>>> On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer <udo@apache.com>
wrote:
>>>>>>> 
>>>>>>> No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd
have
>>>>>> to wait for SBDG 1.3 to use 1.10 or 1.11
>>>>>>> 
>>>>>>> SBDG 1.3 is still a few months off, so maybe getting critical
fixes
>>> in
>>>>>> patch versions is required.
>>>>>>> 
>>>>>>>> On 8/13/19 11:26 AM, Kirk Lund wrote:
>>>>>>>> Udo, Thanks for the info! Sounds like we shouldn't bother
with Geode
>>>>>> 1.9.1
>>>>>>>> then. If I'm misinterpreting what you wrote, let me know.
>>>>>>>> 
>>>>>>>> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer <udo@apache.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> The latest version of SBDG 1.2 is already in RC stage.
Which means
>>>>>> the
>>>>>>>>> dependent Geode version cannot be changed any more. Currently
SBDG
>>>>>> 1.2
>>>>>>>>> is based on Geode 1.9. This will not change. Patch versions
to 1.9
>>>>>> are
>>>>>>>>> supported, but not changes to 1.10 or later.
>>>>>>>>> 
>>>>>>>>> THUS,
>>>>>>>>> 
>>>>>>>>> Once SBDG 1.3 (Neuman) is released, it will be based
on the latest
>>>>>> GA of
>>>>>>>>> Geode, which at this point would be 1.10 or possibly
1.11 depending
>>>>>> on
>>>>>>>>> release cycles.
>>>>>>>>> 
>>>>>>>>> In addition...
>>>>>>>>> 
>>>>>>>>> @Aaron, Whilst it would also be possible to override
the underlying
>>>>>>>>> Geode version that SBDG uses, to a later version, I would
just like
>>>>>> to
>>>>>>>>> point out that all testing of SBDG will be against a
named
>>> supported
>>>>>>>>> version of Geode / GemFire. Which means, if failures
arise using
>>>>>> SBDG /
>>>>>>>>> SDG with a non-supported version of Geode / GemFire would
>>>>>> effectively be
>>>>>>>>> unsupported. (due diligence to confirm origin of failure
will of
>>>>>> course
>>>>>>>>> be applied)
>>>>>>>>> 
>>>>>>>>> Hope this helps...
>>>>>>>>> 
>>>>>>>>> --Udo
>>>>>>>>> 
>>>>>>>>>> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
>>>>>>>>>> Assuming Geode 1.10 is released with the three logging
fixes in
>>>>>> Kirk’s
>>>>>>>>> message, can the next GA release of Spring Boot Data
Geode consume
>>>>>> 1.10
>>>>>>>>> instead of 1.9? Also, when would SBDG need this patch
release by
>>>>>> (whether
>>>>>>>>> we do a 1.9.1 release or 1.10 release)?
>>>>>>>>>> - Aaron
>>>>>>>>>> 
>>>>>>>>>>> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt
<
>>>>>> bschuchardt@pivotal.io>
>>>>>>>>> wrote:
>>>>>>>>>>> If we release a 1.9.1 I'd like to include the
SSL/NIO fix.
>>> Cluster
>>>>>> SSL
>>>>>>>>> communications with conserve-sockets=false is currently
broken in
>>>>>> 1.9.
>>>>>>>>>>>> On 8/13/19 9:25 AM, Kirk Lund wrote:
>>>>>>>>>>>> I'd like to discuss if and how we can release
Geode 1.9.1 with
>>>>>> logging
>>>>>>>>>>>> improvements. This is primarily to provide
a patch release for
>>>>>> Spring
>>>>>>>>> Data
>>>>>>>>>>>> Geode and Spring Boot to ensure a smoother
User experience
>>>>>> out-of-the
>>>>>>>>> box.
>>>>>>>>>>>> They have very near-future releases that
need this as soon as
>>>>>> possible.
>>>>>>>>>>>> 
>>>>>>>>>>>> The specific tickets and commits that would
be back-ported are:
>>>>>>>>>>>> 
>>>>>>>>>>>> *1. GEODE-7058 Log4j-core dependency should
be optional in
>>>>>> geode-core*
>>>>>>>>>>>> 
>>>>>>>>>>>> commit 413800bc16d05df689a2af5c30797f180aad6088
>>>>>>>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>>>>>>>> Date:   Wed Aug 7 14:33:21 2019 -0700
>>>>>>>>>>>> 
>>>>>>>>>>>>    GEODE-7058: Mark log4j-core optional in
geode-core
>>>>>>>>>>>> 
>>>>>>>>>>>>    Note: this change requires all commits
from GEODE-2644 and
>>>>>>>>> GEODE-6122.
>>>>>>>>>>>> *2. GEODE-7050 Log4jAgent should avoid casting
non-log4j
>>> loggers*
>>>>>>>>>>>> 
>>>>>>>>>>>> commit e5c9c420f462149fd062847904e3435fbe99afb4
>>>>>>>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>>>>>>>> Date:   Thu Aug 8 18:17:32 2019 -0700
>>>>>>>>>>>> 
>>>>>>>>>>>>    GEODE-7050: Use Log4jAgent only if Log4j
is using
>>>>>> Log4jProvider
>>>>>>>>> (#3892)
>>>>>>>>>>>>    This change prevents Geode from using
Log4jAgent if Log4j
>>>>>> Core is
>>>>>>>>>>>>    present but not using Log4jProvider.
>>>>>>>>>>>> 
>>>>>>>>>>>>    For example, Log4j uses SLF4JProvider
when log4j-to-slf4j
>>> is
>>>>>> in
>>>>>>>>> the
>>>>>>>>>>>>   classpath.
>>>>>>>>>>>> 
>>>>>>>>>>>>    By disabling Log4jAgent when other Log4j
Providers are in
>>>>>> use,
>>>>>>>>> this
>>>>>>>>>>>>    prevents problems such as ClassCastExceptions
when
>>> attemping
>>>>>> to
>>>>>>>>> cast
>>>>>>>>>>>>    loggers from org.apache.logging.slf4j.SLF4JLogger
to
>>>>>>>>>>>>    org.apache.logging.log4j.core.Logger to
get the
>>> LoggerConfig
>>>>>> or
>>>>>>>>>>>>    LoggerContext.
>>>>>>>>>>>> 
>>>>>>>>>>>>    Co-Authored-By: Aaron Lindsey <alindsey@pivotal.io>
>>>>>>>>>>>> 
>>>>>>>>>>>> *3. GEODE-6959 NPE if AlertAppender is not
defined*
>>>>>>>>>>>> 
>>>>>>>>>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
>>>>>>>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>>>>>>>> Date:   Thu Aug 8 14:59:44 2019 -0700
>>>>>>>>>>>> 
>>>>>>>>>>>>    GEODE-6959: Prevent NPE in GMSMembershipManager
for null
>>>>>>>>> AlertAppender
>>>>>>>>>>>> (#3899)
>>>>>>>>>>>> 
>>>>>>>>>>>>    If a custom log4j2.xml is used without
specifying the Geode
>>>>>>>>>>>> AlertAppender,
>>>>>>>>>>>>    GMSMembershipManager may throw a NullPointerException
when
>>>>>>>>> invoking
>>>>>>>>>>>>    AlertAppender.getInstance().stopSession()
during a
>>>>>>>>> forceDisconnect. This
>>>>>>>>>>>>    change prevents the NullPointerException
allowing
>>>>>> forceDisconnect
>>>>>>>>> to
>>>>>>>>>>>> finish.
>>>>>>>>>>>> 
>>>>>>>>>>>>    Users using Spring Boot with Logback are
more likely to hit
>>>>>> this
>>>>>>>>> bug.
>>>>>>>>>>>>    Co-authored-by: Mark Hanson mhanson@pivotal.io
>>>>>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> -John
>>>>> john.blum10101 (skype)
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> -John
>>>> john.blum10101 (skype)
>>>> 
>>> 
>>> 
>>> --
>>> -John
>>> john.blum10101 (skype)
>>> 


Mime
View raw message