geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Barnes <dbar...@apache.org>
Subject Re: [DISCUSS] Release Geode 1.9.1 with logging improvements
Date Mon, 19 Aug 2019 16:31:01 GMT
I'll update the docs:
 - Geode user guide
 - Geode API docs
 - Native client user guide
 - Native client API docs
 - Apache Geode website

On Mon, Aug 19, 2019 at 9:26 AM Owen Nichols <onichols@pivotal.io> wrote:

> I will pair with you on a 1.9.1 release.
>
> > On Aug 19, 2019, at 9:23 AM, Kirk Lund <klund@apache.org> wrote:
> >
> > I volunteer to pair with a more experienced release manager for 1.9.1.
> > Anyone willing to mentor me on this?
> >
> > On Sun, Aug 18, 2019 at 7:53 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