geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: [DISCUSS] Release Geode 1.9.1 with logging improvements
Date Wed, 28 Aug 2019 21:38:31 GMT
Let's reopen the vote!

On Wed, Aug 28, 2019 at 1:49 PM Kirk Lund <klund@apache.org> wrote:

> Do folks actually want a 1.9.1 release?
>
> On Wed, Aug 28, 2019 at 1:38 PM Owen Nichols <onichols@pivotal.io> wrote:
>
>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message