Re: Should Geode stats conform to backwards compatibility constraints?

[Michael Oleske]

Here's a PR for a revert of the offending commits.

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

Seems valuable to revert for now and decide a path forward rather than rush
to get in 1.9

-michael

On Wed, Feb 13, 2019 at 9:51 PM Jacob Barrett  wrote:

> How about mod MAX_INT? It would wrap back to 0 and make it more consistent
> with at least SNMP counters that roll over to 0 when maxed. A monitoring
> and graphing system can account for this by recognizing the current value
> is less than the previous and typically uses the previous and current
> values to recreate the true value.
>
> -Jake
>
>
> > On Feb 13, 2019, at 8:22 PM, Ryan McMahon  wrote:
> >
> > Sorry that should read “and if the value exceeds MAX_INT”
> >
> >> On Wed, Feb 13, 2019 at 8:21 PM Ryan McMahon 
> wrote:
> >>
> >> +1 to introducing a new method which returns the stat as long per Jake’s
> >> suggestion.  I vote for getInt() to downcast as an int, and the value
> >> exceeds MAX_INT, return MAX_INT and possibly add a warning message which
> >> points users to the new long version of the method.  I think throwing an
> >> exception might be a bit much personally.
> >>
> >> Ryan
> >>
> >>> On Wed, Feb 13, 2019 at 4:24 PM Owen Nichols 
> wrote:
> >>>
> >>> Is it possible for the underlying counter to be maintained as a long,
> and
> >>> change the getInt method to return as normal when the value is within
> >>> MAX_INT, otherwise throw an exception and/or return MAX_INT when the
> long
> >>> value would overflow an int?
> >>>
> >>> For the MX Bean, should we keep (but deprecate) the existing attribute,
> >>> and add a new attribute TotalNetSearchCompletedAsLong?
> >>>
>  On Feb 13, 2019, at 3:58 PM, Kirk Lund  wrote:
> 
>  Quite a few Geode stats are currently defined as IntCounters which
> very
>  easily wrap past Integer.MAX_VALUE. Some users wanted these stats to
> not
>  wrap to negative MAX_VALUE, so my team defined the following two
> tickets
>  and changed them to LongCounters on the develop branch:
> 
>  GEODE-6345: StatSamplerStats jvmPauses stat may wrap to negative value
>  https://issues.apache.org/jira/browse/GEODE-6345
> 
>  GEODE-6334: CachePerfStats operation count stats may wrap to negative
> >>> values
>  https://issues.apache.org/jira/browse/GEODE-6334
> 
>  Some people are now concerned that this may break backwards
> >>> compatibility
>  and API for existing users.
> 
>  There are two potential ways for a user to *experience* this as an API
>  change:
> 
>  1) MemberMXBean in JMX
> 
>  *-  int getTotalNetSearchCompleted();*
>  *+  long getTotalNetSearchCompleted();*
> 
>  As you can see in GEODE-6334, we changed quite a few stats from
> integer
> >>> to
>  long in CachePerfStats. The only one directly exposed as an attribute
> on
>  MemberMXBean is TotalNetSearchCompleted.
> 
>  Users will find that this API method changed.
> 
>  2) Statistics API with undocumented strings
> 
>  If we assume that users might know or discover that we have a
> statistics
>  text id of "cachePerfStats" with an integer stat of name "puts" then
> >>> they
>  could use our Statistics API to get the value:
> 
>  * 1:CacheFactory cacheFactory = new CacheFactory();*
>  * 2:Cache cache = cacheFactory.create();*
>  * 3:*
>  * 4:Region region = cache.  String>createRegionFactory(PARTITION).create("region");*
>  * 5:*
>  * 6:Statistics[] statistics =
> 
> cache.getDistributedSystem().findStatisticsByTextId("cachePerfStats");*
>  * 7:int oldPuts = statistics[0].getInt("puts");*
>  * 8:*
>  * 9:region.put("some", "value");*
>  *10:*
>  *11:int newPuts = statistics[0].getInt("puts");*
>  *12:*
>  *13:assertThat(newPuts).isEqualTo(oldPuts + 1);*
> 
>  The above works in Geode 1.8 and earlier but will begin to throw the
>  following in Geode 1.9 (when develop branch is released):
> 
>  *java.lang.IllegalArgumentException: The statistic puts with id 23 is
> of
>  type long and it was expected to be an int.*
>  * at
> 
> >>>
> org.apache.geode.internal.statistics.StatisticDescriptorImpl.checkInt(StatisticDescriptorImpl.java:324)*
>  * at
> 
> >>>
> org.apache.geode.internal.statistics.StatisticsImpl.getIntId(StatisticsImpl.java:577)*
>  * at
> 
> >>>
> org.apache.geode.internal.statistics.StatisticsImpl.getInt(StatisticsImpl.java:274)*
>  * at
> 
> >>>
> org.apache.geode.internal.statistics.StatisticsImpl.getInt(StatisticsImpl.java:269)*
>  * at com.user.example.Example.example(Example.java7)*
> 
>  In order to avoid the above exception, a user would have to change the
> >>> code
>  on lines 7 and 11 to use *getLong* instead of *getInt*.
> 
>  Should Geode stats be considered a form of API contract and should
> they
>  conform to backwards comp

Re: Geode 1.9 Release Manager

[Michael Oleske]

I have merged https://github.com/apache/geode/pull/3195 just now.

-michael

On Fri, Feb 15, 2019 at 8:27 AM Sai Boorlagadda 
wrote:

> BTW, Is PR #3195 is planned to merge today?
>
> On Fri, Feb 15, 2019 at 7:53 AM Sai Boorlagadda  >
> wrote:
>
> > I am planning to cut the1.9 release branch today after merging this
> > PR #3195 which is reverting changes to GEODE-6334 & GEODE-6345.
> >
> > Is there anything other than that I should be aware of?
> >
> > Here is the list of issues that were requested to be included into 1.9.
> > If there is any plan to merge any of these today let me know and
> > I can cut the branch after that.
> >
> > GEODE-6334 - CachePerfStats operation count stats may wrap to negative
> > values
> >
> > GEODE-6345 - StatSamplerStats jvmPauses stat may wrap to negative value
> >
> > GEODE-6369 - Cache-creation failure after a successful auto-reconnect
> > causes subsequent NPE
> >
> > GEODE-6391 - Event IDs must be included in the PartitioneRegion messages
> >
> > GEODE-6404 - review use of computeIfAbsent across the code base
> >
> >
> > (experimental and dropped)
> >
> > GEODE-6393 - Replace synchronization lock with AtomicReference for
> > InternalLocator
> >
> >
> > -
> >
> > Sai
> >
> > On Thu, Feb 14, 2019 at 3:21 PM Sai Boorlagadda <
> sai.boorlaga...@gmail.com>
> > wrote:
> >
> >> I didn't mean blocking a release but the release process (including
> >> cutting the branch).
> >>
> >>
> >> I thought there was a consensus about strictly cutting a
> >>
> >> branch[1] with our new fixed minor release cadence and
> >>
> >> only allow critical fixes.
> >>
> >>
> >> I assumed that any critical fixes that are allowed onto the
> >>
> >> release branch are the ones that are identified on the branch
> >>
> >> after it is cut and not the ones that are already known.
> >>
> >>
> >> Correct me if my understanding is wrong.
> >>
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E
> >>
> >> On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag  wrote:
> >>
> >>> I could not find any DISCUSS mails about not blocking a release. I may
> be
> >>> wrong, I apologize for that but could point me to the mail /
> >>> documentation
> >>> about the release management.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda <
> >>> sai.boorlaga...@gmail.com>
> >>> wrote:
> >>>
> >>> > Did we not agreed that we won't be blocking a release to include
> fixes
> >>> as
> >>> > we are in a fixed release schedule?
> >>> >
> >>> >
> >>> > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann <
> >>> amurm...@apache.org>
> >>> > wrote:
> >>> >
> >>> > > Usually I am a proponent of cutting a branch and then fixing things
> >>> on
> >>> > > there where things are more stable. In this case we seem to have a
> >>> large
> >>> > > number of fairly serious concerns. Do we think the cost of putting
> >>> this
> >>> > > many fixes on develop + the release branch out-weights the benefit
> of
> >>> > less
> >>> > > risk of new issues being introduced?
> >>> > >
> >>> > > Thoughts?
> >>> > >
> >>> > > Thank you, Sai for taking over!
> >>> > >
> >>> > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda <
> >>> > > sai.boorlaga...@gmail.com>
> >>> > > wrote:
> >>> > >
> >>> > > > I volunteer to be the release manager for 1.9.
> >>> > > >
> >>> > > > Sai
> >>> > > >
> >>> > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann <
> >>> amurm...@apache.org
> >>> > >
> >>> > > > wrote:
> >>> > > >
> >>> > > > > If there are no other takers, I can act as release manager for
> >>> 1.9
> >>> > and
> >>> > > > will
> >>> > > > > cut a release branch this week.
> >>> > > > >
> >>> > > > >
> >>> > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann <
> >>> > amurm...@apache.org
> >>> > > >
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > Hi everyone!
> >>> > > > > >
> >>> > > > > > February 1st is approaching rapidly which means it's almost
> >>> time to
> >>> > > cut
> >>> > > > > > the 1.9 release. Who is interested in being the release
> >>> manager for
> >>> > > > 1.9?
> >>> > > > > >
> >>> > > > > > Thank you!
> >>> > > > > >
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
>

Bug Numbers and Trac Numbers in comments

[Michael Oleske]

Hey Geode Dev Friends!

I was reviewing a PR (this one https://github.com/apache/geode/pull/3197)
and made a note that maybe we should remove comments that make references
to bug and trac numbers that people cannot reach (like me for one).  Kirk
mentioned that some people (like him) have access to those bugs and have
proven helpful for some history.  So there is this balance between noise
(people who cannot access those old issues) and getting context (people who
can access those issues).

So I guess my point is to start a discussion on what a path forward might
be (if any)?  My opinion is that they are noise and we should remove them.
If someone has access to the original issue, then making sure there is a
test case covering it should be done.  Then it makes even more sense to me
to remove the comment.

-michael

Re: [Geode Build] Are the idea and eclipse plugins being used by anyone?

[Michael Oleske]

I tend to import into Intellij the way you have described.  I've never
used ./gradlew
idea to configure.

-michael

On Wed, Apr 3, 2019 at 2:24 PM Patrick Rhomberg 
wrote:

> I'm eyeballing the ide.gradle file we have and am wondering if it is cruft
> from many iterations of both Gradle and IntelliJ/Eclipse ago.
>
> In my own IntelliJ workflow, I have always just asked IntelliJ to open the
> gradle project via the build.gradle itself, and it's easy to import other
> modules into my workspace via Import Module from Existing Sources...  I've
> never had to deal with running ./gradlew idea to configure a project IML
> which I needed to merge against another project file.
>
> Is this the workflow others are using?  Or is the idea plugin here a
> hanger-on that should be removed as no longer necessary?
>
> Also, as an IntelliJ user, I have zero experience on how the workflow for
> Eclipse is similar or different.  The closures in our ide.gradle appear to
> be similar, but I don't have the Eclipse-side context to confirm or deny
> that.
>
> Thanks in advance for any additional insight.
>
> Imagination is Change.
> ~Patrick
>

Re: How to run PulseAuthorizationTest

[Michael Oleske]

These test require you to have the Chrome Driver from Selenium.  You can
find it here

https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver

If you are on a Mac, you can probably (haven't tested this in awhile) use
brew with this command

brew cask install chromedriver

-michael

On Mon, Apr 22, 2019 at 12:15 PM Kirk Lund  wrote:

> Is there a way to run a geode-pulse uiTest on the command-line without it
> failing due to "webdriver.chrome.driver system property"? I would expect
> the gradle build to be setting this property.
>
> $ ./gradlew geode-pulse:uiTest --tests PulseAuthorizationTest
>
> ...
>
> > Task :geode-pulse:uiTest
>
> org.apache.geode.tools.pulse.tests.ui.PulseAuthorizationTest >
> authenticatedUserWithNoClusterReadPermissionShouldGetAccessDeniedPage
> FAILED
> java.lang.IllegalStateException: The path to the driver executable must
> be set by the webdriver.chrome.driver system property; for more
> information, see https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver.
> The latest version can be downloaded from
> http://chromedriver.storage.googleapis.com/index.html
>
> org.apache.geode.tools.pulse.tests.ui.PulseAuthorizationTest >
>
> authenticatedUserWithClusterReadButNoDataReadPermissionShouldSeeClusterDetailsButGetAccessDeniedPageForDataBrowser
> FAILED
> java.lang.IllegalStateException: The path to the driver executable must
> be set by the webdriver.chrome.driver system property; for more
> information, see https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver.
> The latest version can be downloaded from
> http://chromedriver.storage.googleapis.com/index.html
>
> 2 tests completed, 2 failed
>
> > Task :geode-pulse:uiTest FAILED
>

Re: [VOTE] Apache Geode 1.9.0 RC4

[Michael Oleske]

+1
Built geode-native with clang against geode build from source.  Ran
geode-native integration test suite.  Built and ran C++ examples.  All done
on clang.

-michael

On Wed, Apr 24, 2019 at 2:29 PM Charlie Black  wrote:

> +1 Geode Native client built on my Mac successfully.
>
> On Wed, Apr 24, 2019 at 10:53 AM Nabarun Nag  wrote:
>
> > +1
> >
> >- Source version on gfsh version matches the git repos.
> >
> >- Started locator, server, client and did some put / get operations.
> >
> >- Build operations are successful on the source.
> >
> >- Signatures verified.
> >
> >
> > ~/Downloads ⌚ 10:30:50
> > > $ gpg --verify apache-geode-1.9.0-src.tgz.asc
> apache-geode-1.9.0-src.tgz
> > > gpg: Signature made Fri Apr 19 11:48:52 2019 PDT
> > > gpg:using RSA key 468A4800EAFB2498
> > > gpg: Good signature from "Owen Nichols " [full]
> > > ~/Downloads ⌚ 10:31:38
> > > $ gpg --verify apache-geode-1.9.0.tgz.asc apache-geode-1.9.0.tgz
> > > gpg: Signature made Fri Apr 19 11:51:48 2019 PDT
> > > gpg:using RSA key 468A4800EAFB2498
> > > gpg: Good signature from "Owen Nichols " [full]
> > > ~/Downloads ⌚ 10:32:58
> > > $ gpg --verify apache-geode-examples-1.9.0.tar.gz.asc
> > > apache-geode-examples-1.9.0.tar.gz
> > > gpg: Signature made Fri Apr 19 15:59:05 2019 PDT
> > > gpg:using RSA key 468A4800EAFB2498
> > > gpg: Good signature from "Owen Nichols " [full]
> > > ~/Downloads ⌚ 10:33:15
> > > $ gpg --verify apache-geode-examples-1.9.0.zip.asc
> > > apache-geode-examples-1.9.0.zip
> > > gpg: Signature made Fri Apr 19 15:59:06 2019 PDT
> > > gpg:using RSA key 468A4800EAFB2498
> > > gpg: Good signature from "Owen Nichols " [full]
> > > ~/Downloads ⌚ 10:33:44
> > > $ gpg --verify apache-geode-native-1.9.0-src.tar.gz.asc
> > > apache-geode-native-1.9.0-src.tar.gz
> > > gpg: Signature made Fri Apr 19 16:25:20 2019 PDT
> > > gpg:using RSA key
> > DB5476815A475574577D442B468A4800EAFB2498
> > > gpg: Good signature from "Owen Nichols " [full]
> >
> >
> >
> >
> >-
> >
> > Regards
> > Nabarun Nag
> >
> > On Wed, Apr 24, 2019 at 8:36 AM Ryan McMahon 
> wrote:
> >
> > > +1 Verified signatures, compiled from source, and ran all examples.
> > >
> > > Ryan
> > >
> > > On Tue, Apr 23, 2019 at 3:44 PM Owen Nichols 
> > wrote:
> > >
> > > > +1
> > > >
> > > > I used gpg --verify to check all signatures, compiled geode from
> > source,
> > > > ran all examples, and set up a cluster with 2 locators, 3 servers, a
> > > simple
> > > > client and SSL enabled.
> > > >
> > > > -Owen
> > > >
> > > >
> > > > > On Apr 23, 2019, at 1:32 PM, Dan Smith  wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > Looks good to me. I ran the geode-release-check against the repo.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Fri, Apr 19, 2019 at 5:00 PM Owen Nichols  > > > > wrote:
> > > > >
> > > > >> Hello, Geode dev community,
> > > > >>
> > > > >>
> > > > >> This is the fourth release candidate for Apache Geode, version
> > 1.9.0.
> > > > >>
> > > > >> Thanks to all the community members for their contributions to
> this
> > > > >> release!
> > > > >>
> > > > >>
> > > > >> Please do a review and give your feedback. The deadline is before
> 3
> > PM
> > > > PST
> > > > >> Wed April 24th, 2019.
> > > > >>
> > > > >>
> > > > >> 1.9.0 resolves 296 issues on Apache Geode JIRA system. Release
> notes
> > > > >> can be found at:
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > > > >> <
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.0
> > > > >
> > > > >>>
> > > > >>
> > > > >>
> > > > >> Please note that we are voting upon the source tags:
> rel/v1.9.0.RC4
> > > > >>
> > > > >>
> > > > >> Apache Geode:
> > > > >>
> > > > >> https://github.com/apache/geode/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode/tree/rel/v1.9.0.RC4> <
> > > > >> https://github.com/apache/geode/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode/tree/rel/v1.9.0.RC4>>
> > > > >>
> > > > >> Apache Geode examples:
> > > > >>
> > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4> <
> > > > >> https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode-examples/tree/rel/v1.9.0.RC4>>
> > > > >>
> > > > >> Apache Geode Native:
> > > > >>
> > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4> <
> > > > >> https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4 <
> > > > https://github.com/apache/geode-native/tree/rel/v1.9.0.RC4>>
> > > > >>
> > > > >>
> > > > >> Commit ID:
>

Pulse - Non-Embedded Mode

[Michael Oleske]

Hi Geode Community!

Some colleagues and I were looking at GEODE-6683 (
https://issues.apache.org/jira/browse/GEODE-6683) and noticed that we do
not have test coverage for running Pulse in non-embedded mode.  We were
wondering what our strategy is around Pulse in non-embedded mode. In order
to fully fix the issue, we would prefer to have a high-level acceptance
test that actually tries to run Pule in non-embedded mode (we could not
find an existing acceptance test that performs this).   However, this
non-embedded mode seems a bit odd, as the instructions for it (
https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html)
are slightly confusing and need some updating for geode (such as making
sure geode-core is on the class path). It seems strange to try and host a
web app in this way, especially with the extra configuration needed (cannot
just plop the Pulse war file in my web server with some config and have it
work).  So there's some questions about the best path forward.

1.  Should we continue supporting non-embedded mode for Pulse?  It seems
like it may be useful to allow Pulse to run outside of a member, but not as
it currently does.  If it was deprecated, I wouldn't be as insistent on an
acceptance test for it.

2.  Should we try to make a separate artifact that is intended to be
deployed on a web server?  This would have a new artifact that could run
elsewhere then (with maybe a user provided config file for properties.)

3.  For the issue that brought up these questions (GEODE-6683), we have
currently only written some unit tests to add the properties. So the
current question is what type of path forward should we take?


-michael

Re: [DISCUSS] is it time to make Windows tests gating?

[Michael Oleske]

Agreed on making them gating if we want to say we run on Windows. If we
don't want to say we run on Windows, delete the jobs.

-michael

On Thursday, May 16, 2019, Anilkumar Gingade  wrote:

> >> around 5 hours, vs 2 hours for Linux tests).
> May be a good time to look at reducing/optimizing this.
>
>
> On Thu, May 16, 2019 at 9:57 AM Ernest Burghardt 
> wrote:
>
> > Yes make them gating.
> > Run them every commit, Windows is a supported platform.
> > Red boxes get attention and Red boxes get fixed.
> >
> > EB
> >
> > On Thu, May 16, 2019 at 1:09 AM Udo Kohlmeyer  wrote:
> >
> > > I think we need to make sure our windows tests get to green... If we
> > > make them gating then we will never release, but at the time be
> > > motivated to fix them, in order to release.
> > >
> > > Maybe they run once every day... to at least start getting an idea of
> > > health
> > >
> > > On 5/15/19 18:28, Owen Nichols wrote:
> > > > For a very long time we’ve had Windows tests in the main pipeline
> > > (hidden away, not in the default view), but the pipeline proceeds to
> > > publish regardless of whether Windows tests fail or even run at all.
> > > >
> > > > Now seems like a good time to review whether to:
> > > > a) treat Windows tests as first-class tests and prevent the pipeline
> > > from proceeding if any test fails on Windows
> > > > b) keep as-is
> > > > c) change Windows tests to trigger only once a week rather than on
> > every
> > > commit, if they are going to remain "informational only"
> > > >
> > > > One disadvantage to making Windows tests gating is that they
> currently
> > > take much longer to run (around 5 hours, vs 2 hours for Linux tests).
> > >
> >
>

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[Michael Oleske]

Seems alright to me given the context that you're trying to separate code
into modules (and want to make sure you're not including packages you
shouldn't).  Looking forward to see how the progress goes!

-michael

On Thu, Jun 20, 2019 at 4:35 PM Dan Smith  wrote:

> We don't have a membership gradle module, just a package. We're adding this
> to geode-core.
>
> For a little more context - we are thinking about refactoring membership
> (and/or maybe some other pieces) into separate gradle modules - proposal
> forthcoming! However, as a first step we need to untangle those pieces of
> code from the rest of geode-core. Rather than creating some long lived
> branch we can incrementally untangle the code a piece at a time, on
> develop. Having a way to track progress and enforce the direction of
> dependencies on the way to a separate gradle module will help with that.
>
> -Dan
>
> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett  wrote:
>
> > Are you adding this dependency to just the membership module? I am cool
> > with that.
> >
> > > On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
> > >
> > > Hi all,
> > >
> > > Bill, Ernie, and I would like to add a new (apache licensed) test
> > > dependency to geode-core - https://github.com/TNG/ArchUnit. This is a
> > tool
> > > that lets you write tests that make assertions about the
> > interdependencies
> > > of your code - for example enforcing that package A does not depend on
> > > package B.
> > >
> > > Initially we intend to add some tests about what parts of the system
> the
> > > org.apache.geode.distributed.internal.membership package depends on,
> with
> > > an eye towards making that code more independently testable (proposal
> on
> > > that coming soon!).
> > >
> > > Does anyone have an issue with adding this test dependency?
> > >
> > > -Dan
> >
> >
>

Re: New release branch for Apache Geode 1.10.0

[Michael Oleske]

Naba's concern was this PR: https://github.com/apache/geode/pull/3880 which
has been merged to develop

-michael

On Fri, Aug 2, 2019 at 4:33 PM Owen Nichols  wrote:

> Hi Naba, thank you for bringing your concern.
>
> Our current process <
> https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E>
> dictates a time-based schedule to cut release branches.  Once cut, the
> “critical fixes” rule allows critical fixes to be brought to the release
> branch by proposal on the dev list.
>
> Currently the 1.10.0 release pipeline <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-main>
> is all green.  Perhaps one way to convince the Geode community that your
> fix satisfies the “critical fixes” rule might be to share a link to a
> github commit adding tests that expose the issue.
>
> Thanks,
> -Owen
>
>
> > On Aug 2, 2019, at 12:55 PM, Nabarun Nag  wrote:
> >
> > Hi,
> >
> > We believe that the current release branch has an issue of getting a
> > NullPointerException when we try calling LocalRegion.getLocalSize when
> the
> > region is in the process of being initialized. The fix for this issue is
> > very critical and we should re-create the branch when the fix is placed
> in
> > develop.
> > We need to hold any pipeline testing on the branch till this fix is in.
> >
> > Regards
> > Nabarun Nag
> >
> > On Fri, Aug 2, 2019 at 11:17 AM Dick Cavender  wrote:
> >
> >> Hello Geode Dev Community,
> >>
> >> We have created a new release branch for Apache Geode 1.10.0 -
> >> "release/1.10.0"
> >>
> >> Please do review and raise any concern with the release branch. If no
> >> concerns are raised, we will start with the voting for the release
> >> candidate soon.
> >>
> >> Regards
> >>
> >> Dick Cavender
> >> Apache Geode 1.10.0 Release Manager
> >>
>
>

Re: ./gradlew test no longer runs/reruns tests?

[Michael Oleske]

For more information/background on gradle and running tests, I suggest
reading this blog post from the gradle team

https://blog.gradle.org/stop-rerunning-tests

-michael

On Wed, Aug 7, 2019 at 11:58 AM Jacob Barrett  wrote:

> Gradle has, for as long as I can recall, always had this behavior for unit
> tests. The default in Gradle Test plugin is to not rerun tests unless the
> main sources have changed. For integration, distributed and acceptance
> tests we have changed that default to always run regardless of source
> changes.
>
> > On Aug 7, 2019, at 10:08 AM, Kirk Lund  wrote:
> >
> > I used to use "./gradlew test" to run or rerun unit tests but it no
> longer
> > works. It seems to just early out... maybe gradle thinks that the unit
> > tests were already run so it doesn't need to rerun them.
> >
> > Is this intentional? I assume some gradle changes were made that changed
> > this behavior.
>

Updating geode-native-build docker image

[Michael Oleske]

Hi Geode Devs!

Geode Native merged https://github.com/apache/geode-native/pull/509 this
morning since our docker image was using an old Geode version.  What is the
proper way to update docker hub (
https://hub.docker.com/r/apachegeode/geode-native-build) with the new
image?  Is that something committers should be able to do?  Or is there an
automated build that updates docker hub?

Thanks!
-michael

Re: Gradle daemon crashed in PR precheckin

[Michael Oleske]

Not sure what the exact issue in this particular case, but I suspect we
might not want to run with the Gradle daemon in CI.  The Gradle daemon is
really meant to help local building (see
https://docs.gradle.org/current/userguide/gradle_daemon.html).  That link
explicitly calls out that you may not want to use the Gradle daemon in CI,
so we could use the --no-daemon flag to disable the Gradle daemon in CI if
we feel that would help eliminate extra problems.

-michael

On Thu, Aug 22, 2019 at 10:36 AM Kirk Lund  wrote:

> Can someone please look at
> https://concourse.apachegeode-ci.info/builds/88869 and help me determine
> what happened to the Gradle daemon?
>
> > Task :geode-assembly:distributedTest
>  
> > Task :geode-core:distributedTest
>  
>  
> The message received from the daemon indicates that the daemon has
> disappeared.
>  
> Build request sent: Build{id=0311dae5-5824-4303-acfe-ceb50507a6a4,
> currentDir=/home/geode/geode}
>  
> Attempting to read last messages from the daemon log...
>  
> Daemon pid: 5950
>  
>   log file: /home/geode/.gradle/daemon/5.4/daemon-5950.out.log
>  
> - Last  20 lines from daemon log file - daemon-5950.out.log -
>  
> Note: Some input files use or override a deprecated API.
>  
> Note: Recompile with -Xlint:deprecation for details.
>  
> Note: Some input files use unchecked or unsafe operations.
>  
> Note: Recompile with -Xlint:unchecked for details.
>  
> Note: Some input files use or override a deprecated API.
>  
> Note: Recompile with -Xlint:deprecation for details.
>  
> Note: Some input files use unchecked or unsafe operations.
>  
> Note: Recompile with -Xlint:unchecked for details.
>  
> Note: Some input files use or override a deprecated API.
>  
> Note: Recompile with -Xlint:deprecation for details.
>  
> Note: Some input files use unchecked or unsafe operations.
>  
> Note: Recompile with -Xlint:unchecked for details.
>  
> Note: Some input files use or override a deprecated API.
>  
> Note: Recompile with -Xlint:deprecation for details.
>  
> Note: Some input files use unchecked or unsafe operations.
>  
> Note: Recompile with -Xlint:unchecked for details.
>  
> Note: Some input files use or override a deprecated API.
>  
> Note: Recompile with -Xlint:deprecation for details.
>  
> Note: Some input files use unchecked or unsafe operations.
>  
> Note: Recompile with -Xlint:unchecked for details.
>  
> - End of the daemon log -
>  
>  
>  
> FAILURE: Build failed with an exception.
>  
>  
> * What went wrong:
>  
> Gradle build daemon disappeared unexpectedly (it may have been killed
> or may have crashed)
>  

Propose including GEODE-7178 in 1.10

[Michael Oleske]

Hi Geode Devs!

I'd like to propose including the fix for GEODE-7178.  This resolves an
issue that Ivan (https://markmail.org/message/dwwac42xmpo4xb2e) ran into in
1.10 RC1.

SHA: 91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
Link to GitHub:
https://github.com/apache/geode/commit/91176d61df64bf1390cdba7b1cdc2b40cdfaba3a

Thanks!
-michael

Re: Propose including GEODE-7178 in 1.10

[Michael Oleske]

Here is the Pull Request for the cherry pick as requested
https://github.com/apache/geode/pull/4049

-michael

On Thu, Sep 12, 2019 at 10:28 AM Dick Cavender  wrote:

> Hi Michael, thank you for bringing your concern and fixing this issue.
>
> Geode's release process dictates a time-based schedule <
> https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule> to cut
> release branches.  The “critical fixes” rule does allow critical fixes to
> be brought to the release branch by proposal on the dev list, as you have
> done here.
>
> If there is consensus from the Geode community that your proposed change
> satisfies the “critical fixes” rule, I will be happy to bring it to the
> 1.10.0 release branch.
>
> Due to the complexity of this change, could please open a PR against
> release/1.10.0 containing the exact changes you want to merge?
>
> Regards
>
> -Dick
>
>
> On Thu, Sep 12, 2019 at 10:23 AM Anthony Baker  wrote:
>
> > +1 yes please!
> >
> > > On Sep 12, 2019, at 10:11 AM, Michael Oleske 
> wrote:
> > >
> > > Hi Geode Devs!
> > >
> > > I'd like to propose including the fix for GEODE-7178.  This resolves an
> > > issue that Ivan (https://markmail.org/message/dwwac42xmpo4xb2e) ran
> > into in
> > > 1.10 RC1.
> > >
> > > SHA: 91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> > > Link to GitHub:
> > >
> >
> https://github.com/apache/geode/commit/91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> > >
> > > Thanks!
> > > -michael
> >
> >
>

Re: Propose including GEODE-7178 in 1.10

[Michael Oleske]

The native client does behave as an old Java client (ordinal 45).  I have
written a story (https://issues.apache.org/jira/browse/GEODE-7190) to have
Native Client updated.

-michael

On Thu, Sep 12, 2019 at 2:35 PM Dan Smith  wrote:

> +1 for getting this in 1.10.
>
> I am curious though - is the native client behaving like an older versions
> of the java client, or is this totally unique behavior for the native
> client? Is there some integration test that we are missing here?
>
> -Dan
>
> On Thu, Sep 12, 2019 at 11:52 AM Michael Oleske 
> wrote:
>
> > Here is the Pull Request for the cherry pick as requested
> > https://github.com/apache/geode/pull/4049
> >
> > -michael
> >
> > On Thu, Sep 12, 2019 at 10:28 AM Dick Cavender 
> > wrote:
> >
> > > Hi Michael, thank you for bringing your concern and fixing this issue.
> > >
> > > Geode's release process dictates a time-based schedule <
> > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule> to
> > cut
> > > release branches.  The “critical fixes” rule does allow critical fixes
> to
> > > be brought to the release branch by proposal on the dev list, as you
> have
> > > done here.
> > >
> > > If there is consensus from the Geode community that your proposed
> change
> > > satisfies the “critical fixes” rule, I will be happy to bring it to the
> > > 1.10.0 release branch.
> > >
> > > Due to the complexity of this change, could please open a PR against
> > > release/1.10.0 containing the exact changes you want to merge?
> > >
> > > Regards
> > >
> > > -Dick
> > >
> > >
> > > On Thu, Sep 12, 2019 at 10:23 AM Anthony Baker 
> > wrote:
> > >
> > > > +1 yes please!
> > > >
> > > > > On Sep 12, 2019, at 10:11 AM, Michael Oleske 
> > > wrote:
> > > > >
> > > > > Hi Geode Devs!
> > > > >
> > > > > I'd like to propose including the fix for GEODE-7178.  This
> resolves
> > an
> > > > > issue that Ivan (https://markmail.org/message/dwwac42xmpo4xb2e)
> ran
> > > > into in
> > > > > 1.10 RC1.
> > > > >
> > > > > SHA: 91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> > > > > Link to GitHub:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/geode/commit/91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> > > > >
> > > > > Thanks!
> > > > > -michael
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Michael Oleske]

For context, these are the docs for running Pulse as stand alone
https://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_795C97B46B9843528961A094EE520782

The instructions always seemed odd since we tell folks to go "tools/pulse"
to copy the pulse.war file to their dedicated web application server.  I
don't think we have many tests that test that particular configuration
though.

-michael

On Tue, Sep 24, 2019 at 3:44 PM Udo Kohlmeyer  wrote:

> Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
>
> Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
>
> Most likely an oversight...
>
> --Udo
>
> On 9/24/19 3:38 PM, Robert Houghton wrote:
> > The geode-pulse module also builds a war, but does not publish it. Is
> this
> > an oversight, or by design?
> >
> > On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> > wrote:
> >
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
> >>
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Michael Oleske]

+1

built and ran tests for native client on windows.

-michael

On Wed, Oct 16, 2019 at 2:21 PM Blake Bender  wrote:

> Okay I'm convinced we're okay, so switching to a +1.  Standard PEBKAC error
> here, I managed to produce a native client build which was missing the jar
> file we use for a whole bunch of tests, so all failed.
>
> Thanks,
>
> Blake
>
>
> On Wed, Oct 16, 2019 at 1:03 PM Blake Bender  wrote:
>
> > I'm a -1 on this one, for the time being, sorry.  I ran native client
> > integration tests against it on my dev workstation and am seeing an
> > inordinate number of failures.  It's gonna take me some time to
> understand
> > what's going on, but I'll update everyone shortly as to whether I think
> we
> > have a real issue.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Tue, Oct 15, 2019 at 3:29 PM Udo Kohlmeyer  wrote:
> >
> >> Hi there Owen,
> >>
> >> Whilst I share your concern of consistence, the Geode user community did
> >> not notice that the artifacts changed from war -> jar (GEODE-7241). The
> >> Spring Data Geode project is currently the only downstream project which
> >> discovered this regression.
> >>
> >> As Spring Data Geode 2.2 will not be using any other version than 1.9.x,
> >> there is no dependency on 1.10.
> >>
> >> In addition to this, 1.11 is not that far off, and upon discovery of
> >> this regression from 1.9.2 -> 1.10, we most likely could be pointing
> >> them at 1.11 to upgrade.
> >>
> >> As for Spring 5 (GEODE-7261), I might agree that we might want to be
> >> adding that to 1.10.1 patch, but so far I have not seen/heard of any
> >> users hitting this issue. Maybe it would also fall into the category of
> >> "wait for 1.11".
> >>
> >> --Udo
> >>
> >> On 10/15/19 3:05 PM, Owen Nichols wrote:
> >> > I am concerned that this 1.9.2 release contains features that are not
> >> in 1.10:
> >> > GEODE-7241 Publish war artifacts for geode-web , geode-web-api and
> >> geode-web-management to Maven Central.
> >> > GEODE-7261 Fix compatibility with launching geode-web (admin REST API)
> >> when Spring 5.x jars are on the classpath.
> >> >
> >> > My concern is that users of these 1.9.2 fixes will be surprised to
> >> experience a regression when they upgrade to 1.10.0.
> >> >
> >> > This could be addressed by planning a 1.10.1 patch release, or maybe
> >> just by documenting this caveat as long as the Spring Data project can
> >> agree to skip over 1.10, but my non-binding vote is -1 until some plan
> is
> >> in place.
> >> >
> >> > -Owen
> >> >
> >> >> On Oct 15, 2019, at 10:47 AM, Jens Deppe 
> wrote:
> >> >>
> >> >> Hello Geode Dev Community,
> >> >>
> >> >> This is a release candidate for Apache Geode version 1.9.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 Sun, October 20 2019.
> >> >>
> >> >> Please note that we are voting upon the source tag:
> >> >> rel/v1.9.2.RC1
> >> >>
> >> >> Release notes:
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> >> >>
> >> >> Source and binary distributions:
> >> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> >> >>
> >> >> Maven staging repo:
> >> >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >> >>
> >> >> GitHub:
> >> >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> >> >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> >> >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> >> >>
> >> >> Pipelines:
> >> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> >> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> >> >>
> >> >> Geode's KEYS file containing PGP keys we use to sign the release:
> >> >> https://github.com/apache/geode/blob/develop/KEYS
> >> >>
> >> >> Command to run geode-examples:
> >> >> ./gradlew -PgeodeReleaseUrl=
> >> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> >> -PgeodeRepositoryUrl=
> >> >>
> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >> >> build runAll
> >> >>
> >> >> Regards
> >> >> --Jens
> >> >
> >>
> >
>

Re: Odg: gateway sender queue

[Michael Oleske]

>
> vsd stat in the gfs file
>

Just here to say consider using a meter instead of stat as documented in
https://cwiki.apache.org/confluence/display/GEODE/How+to+add+a+Meter if
more than a log message is warrented.

-michael

On Thu, Nov 14, 2019 at 11:29 AM Nabarun Nag  wrote:

> +1 to Dan's suggestion
>
> What about a log and a vsd stat in the gfs file which tells us if any
> cleanQueue commands were executed.
>
>
> Regards
> Nabarun Nag
>
> On Thu, Nov 14, 2019 at 10:27 AM Udo Kohlmeyer  wrote:
>
> > In addition... making is default has bigger consequences that we have
> > not thought about..
> >
> > e.g if you purge an existing queue on start up.. is this the start up of
> > the server node / GS Queue? Given that we have shared-nothing
> > architecture, purging *should* only be local and not cluster-wide... I'd
> > be interested and see a proposal on this feature.
> >
> > --Udo
> >
> > On 11/14/19 10:24 AM, Jason Huynh wrote:
> > > +1 to Dan's suggestion
> > >
> > > On Thu, Nov 14, 2019 at 9:52 AM Dan Smith  wrote:
> > >
> > >> I'm ok with adding a --cleanQueue option.
> > >>
> > >> However, I don't think it should default to be true, since that would
> be
> > >> changing the behavior of the existing command. It should default to
> > false.
> > >>
> > >> -Dan
> > >>
> > >> On Thu, Nov 14, 2019 at 9:28 AM Xiaojian Zhou 
> wrote:
> > >>
> > >>> The --cleanQueue option is a similar idea as Barry's "DeadLetter"
> > spike.
> > >> I
> > >>> remembered that we decided not to do it.
> > >>>
> > >>>
> > >>> On Wed, Nov 13, 2019 at 11:41 PM Mario Ivanac  >
> > >>> wrote:
> > >>>
> >  Hi,
> > 
> >  just to remind you on last question:
> > 
> >  what is your opinion on adding additional option in gfsh command
> > >> "start
> >  gateway sender"
> >  to control clearing of existing queues --cleanQueues.
> > 
> >  This option will indicate, when gateway sender is started, should we
> >  discard/clean existing queue, or should we use existing queue.
> >  By default it will be to discard/clean existing queue.
> > 
> >  Best Regards,
> >  Mario
> >  
> >  Šalje: Mario Ivanac 
> >  Poslano: 8. studenog 2019. 13:00
> >  Prima: dev@geode.apache.org 
> >  Predmet: Odg: gateway sender queue
> > 
> >  Hi all,
> > 
> >  one more clarification regarding 3rd question:
> > 
> >  "*   Could we add extra option in gfsh command  "start gateway
> sender"
> >    that allows to control queues reset (for instance
> > --cleanQueues)"
> > 
> >  This option will indicate, when gateway sender is started, should we
> >  discard/clean existing queue, or should we use existing queue.
> >  By default it will be to discard/clean existing queue.
> > 
> >  Best Regards,
> >  Mario
> >  
> >  Šalje: Mario Ivanac 
> >  Poslano: 7. studenog 2019. 9:01
> >  Prima: Dan Smith ; dev@geode.apache.org <
> >  dev@geode.apache.org>
> >  Predmet: Odg: gateway sender queue
> > 
> >  Hi,
> > 
> >  thanks for answers.
> > 
> >  Some more details regarding 1st question.
> > 
> >  Is this behavior same (for serial and parallel gateway sender) in
> case
> >  queue is persistent?
> >  Meaning, should queue (persistent) be purged if we restart gateway
> > >>> sender?
> > 
> >  Thanks,
> >  Mario
> > 
> >  
> >  Šalje: Dan Smith 
> >  Poslano: 5. studenog 2019. 18:52
> >  Prima: dev@geode.apache.org 
> >  Predmet: Re: gateway sender queue
> > 
> >  Some replies, inline:
> > 
> > *   During testing we have observed, different behavior in
> parallel
> > >> and
> > > serial gateway senders. In case we manually stop, than start
> gateway
> > > senders, for parallel gateway senders, queue is purged, but for
> > >> serial
> > > gateway senders this is not the case. Is this normal behavior or
> bug?
> > >
> >  Hmm, I also think stop is supposed to clear the queue. I think if
> you
> > >> are
> >  seeing that it doesn't clear the queue, that might be a bug.
> > 
> > 
> > 
> > >*   What happens with the queues when whole cluster is stopped
> and
> >  later
> > > started (In our tests with persistent queues, the events are kept)?
> > >
> >  Persistent queues will keep all of the events when you restart.
> > 
> > 
> > >*   Could we add extra option in gfsh command  "start gateway
> > >> sender"
> > > that allows to control queues reset (for instance --cleanQueues)?
> > >
> >  If stop does clear the queue, would this be needed? It might still
> be
> >  reasonable - I've heard folks request a way to clear running queues
> as
> >  well.
> > 
> >  -Dan
> > 
> >
>

Re: DistributionArchUnitTest OutOfMemoryError

[Michael Oleske]

I've hit the same error as Kirk.  My lazy solution was to just rerun
`./gradlew build` cause that would pass on the second time.

-michael

On Wed, Nov 20, 2019 at 4:53 PM Dan Smith  wrote:

> We recently added this test. It passes for me, but I will look into it. It
> is scanning classes, so that may be your oome.
>
> On Wed, Nov 20, 2019, 4:00 PM Kirk Lund  wrote:
>
> > Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> > doing a "./gradlew build"?
> >
> > I think we should move any unit tests that run OutOfMemoryError out of
> unit
> > tests (to integration tests maybe?).
> >
> > > Task :geode:geode-core:test
> > Heap dump file created [957877145 bytes in 17.227 secs]
> >
> > org.apache.geode.distributed.internal.DistributionArchUnitTest >
> > classMethod FAILED
> > java.lang.OutOfMemoryError: GC overhead limit exceeded
> >
> > 6991 tests completed, 1 failed, 12 skipped
> >
>

PR Checks issues?

[Michael Oleske]

Hi Geode Dev!

This PR https://github.com/apache/geode/pull/4406 is a change to the
readme.  However it took 3 empty commits to get it to go green enough to be
allowed to be merged.  This seems odd, especially with just a readme
change.  Is there something going with how CI works for PRs?  This was an
incredibly frustrating experience.

Thanks!
-michael

Re: PR Checks issues?

[Michael Oleske]

Well lack of review was one part.  The major part was that if you click on
the checks from the other empty commits, you'll see that the required
passing jobs never triggered (only the LGTM checks).

-michael

On Fri, Dec 13, 2019 at 11:43 AM Joey McAllister 
wrote:

> Hi Michael,
>
> That may have been connected, at least in part, to a lack of a review. I
> have given my review on adding this info to the README, which I think looks
> good, and things seem to have gone green.
>
> That said, as I mentioned in my review, I also wouldn't mind seeing a
> thumbs up (or other feedback) from someone else in the community who will
> be using these LGTM alerts regularly.
>
> Best,
> Joey
>
> On Fri, Dec 13, 2019 at 11:31 AM Michael Oleske 
> wrote:
>
> > Hi Geode Dev!
> >
> > This PR https://github.com/apache/geode/pull/4406 is a change to the
> > readme.  However it took 3 empty commits to get it to go green enough to
> be
> > allowed to be merged.  This seems odd, especially with just a readme
> > change.  Is there something going with how CI works for PRs?  This was an
> > incredibly frustrating experience.
> >
> > Thanks!
> > -michael
> >
>

Re: [VOTE] Apache Geode 1.11.0.RC4

[Michael Oleske]

+1

- ran `./gradlew build` on Geode 1.11.0.RC4 on Mac and Windows
- built Geode Native 1.11.0.RC4 against Geode 1.11.0.RC4 on Mac and Windows
- ran `ctest -L STABLE -C Debug` on cppcache/integration-test on Mac and
Windows
- ran `ctest` on cppcache/integration/test on Mac and Windows (Did not test
IPV6 support as I don't generally use that)
- ran `ctest -L STABLE -C Debug` on clicache/integration-test on Windows
- ran XUnit tests in Rider on clicache/integrations-test2 on Windows
- installed and built Geode Native 1.11.0.RC4 examples on Windows

-michael


On Fri, Dec 20, 2019 at 2:49 PM Mark Hanson  wrote:

> Given it is the holidays, perhaps more time is in order. I am bumping the
> voting deadline to Friday, December 27th, 2019.
>
> Thanks,
> Mark
>
>
>
> > On Dec 20, 2019, at 2:46 PM, Mark Hanson  wrote:
> >
> > Subject: [VOTE] Apache Geode 1.11.0.RC4
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.11.0.RC4.
> > 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 Friday, December 27 2019.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.11.0.RC4
> >
> > Release notes:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC4/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1064
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.11.0.RC4
> > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC4
> > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC4
> >
> > Pipelines:
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC4
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1064
> build runAll
> >
> > Regards
> > Mark Hanson
> >
>
>

Re: privacy protection

[Michael Oleske]

Something to consider is what scenarios do you want to protect against.
Full disk encryption protects against a drive pull attack, such as an
attack walks into a data storage room full disks, pulls a disk from the
room, and then makes a run for it.  Since the full disk is encrypted, the
attacker will have to break that.  Encrypting values protects against
insiders from seeing values, such as a rogue administrator that is trying
to get personally identifiable information (they would be able to decrypt
the disk, but wouldn't be able to decrypt the values).  I'm personally not
sure what Geode needs to do or could be doing versus what's best practice
when building applications that use Geode/when running Geode.

-michael

On Tue, Jan 21, 2020 at 10:33 AM Dan Smith  wrote:

> Hi Mario,
>
> It's something we've talked about before, I think it would be a good idea.
> The two workarounds I have seen done are
> - full disk encryption - storing the geode disk files on an encrypted disk
> - encrypting values  - At the client side, converting values into encrypted
> bytes before storing them in geode.
>
> But it would nice to just support encryption at the disk store level.
>
> -Dan
>
> On Tue, Jan 21, 2020 at 4:21 AM Udo Kohlmeyer  wrote:
>
> > Hi there Mario,
> >
> > The idea of encryption-at-rest, is something that has been on my radar
> > for at least 4yrs now.
> >
> > I would not mind having a chat about what your requirements are and how
> > we can get this into Geode.
> >
> > Looking forward to chatting to you about this.
> >
> > --Udo
> >
> > On 1/15/20 2:20 AM, Mario Kevo wrote:
> > > Hi geode-dev,
> > >
> > > Is it possible somehow to protect all files that containing user
> data(or
> > user data itself) being stored in disk for Geode.
> > > This includes all persistence data(OpLogs), backups and possible other
> > files containing user data.
> > > Also protection is needed for all of the files potentailly used for
> > replication and cluster high availability mechanism.
> > >
> > > If this feature is not available, do you have it in the plan already?
> > > Do you included it in Geode roadmap?
> > >
> > > BR,
> > > Mario
> > >
> > >
> >
>

[Polite Request] Clean up branches on Geode

[Michael Oleske]

There's a lot of branches on Geode that look like they can be deleted
because they have either been merged or closed.  Below is a list.  Please
consider deleting your branch if you have created one of the below.

Thanks!
-michael

The following branches on Geode have been merged

feature/GEODE-7212 Updated 2 months ago by karensmolermiller - #4392 -
Merged
feature/GEODE-7477 Updated 2 months ago by Eric Shu - #4352 - Merged
revert-4204-feature/GEODE-7157 Updated 3 months ago by mhansonp - #4283 -
Merged
revert-4201-GEODE-7326-add-cache-gets-timer Updated 3 months ago by
mhansonp - #4222 - Merged
revert-4189-revert-4086-feature/GEODE-6807 Updated 3 months ago by mivanac
- #4212 - Merged
revert-4086-feature/GEODE-6807 Updated 3 months ago by echobravopapa -
#4189 - Merged
revert-4046-feature/GEODE-7179 Updated 4 months ago by nabarunnag - #4054 -
Merged
revert-4034-feature/GEODE-7128 Updated 4 months ago by nabarunnag - #4052 -
Merged
feature/GEODE-7130 Updated 5 months ago by pivotal-eshu - #3973 - Merged
feature/GEODE-6812 Updated 8 months ago by pivotal-eshu - #3682 - Merged
feature/GEODE-6802 Updated 8 months ago by pivotal-eshu - #3623 - Merged

The following branches on Geode have been closed
feature/GEODE-7576 Updated last month by Eric Shu - #4477 - Closed
feature/GEODE-7277 Updated 3 months ago by gesterzhou - #4149 - Closed
better-classpath Updated 14 months ago by metatype - #2904 - Closed

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Michael Oleske]

+1 !!

-michael

On Mon, Mar 23, 2020 at 8:33 AM Aaron Lindsey 
wrote:

> YES +1
>
> > On Mar 23, 2020, at 7:42 AM, Bruce Schuchardt 
> wrote:
> >
> > +1
> >
> > On 3/21/20, 5:17 PM, "Nabarun Nag"  wrote:
> >
> >Hello team,
> >
> >We are planning to experiment with using Github issues and wiki for
> the
> >Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> Please
> >do give your vote on this as we need to send the vote link to infra to
> >activate it.
> >
> >*Why are we doing this ? / Advantages* :
> >1. *Unified location* to have documentation, code and issue tracking.
> >2. Leverage Github tools like Github pages to create websites hosting
> >information about the project.
> >3. No separate JIRA accounts or permission required to create issues.
> >4. This will have *no impact on the broader Geode community* as right
> now
> >only 3-4 developers involved in this project.
> >5. *This is an experiment.* If things do not work out we can always
> revert
> >back to the traditional way of having separate JIRA, documentation,
> >websites etc.
> >
> >*Precedence*:
> >1. Kubernetes uses the github issues
> >2. RabbitMQ uses github issues.
> >
> >
> >*NOTE: *- Please be cordial and do not use any condescending language
> and
> >absolutely no bullying.
> >- Please treat this email as a professional business email and
> maintain
> >email etiquette while replying.
> >
> >Regards
> >Nabarun
> >
> >
> >
>
>

Re: RFC: Add C Bindings to Geode Native Client

[Michael Oleske]

+1

Would certainly be nice since the protobuf work is still mostly
experimental (and then I can continue my goal of Geode-ing all the
languages)

-michael


On Wed, Mar 25, 2020 at 9:03 AM Dan Smith  wrote:

> +1
>
> Great idea! Hey, it's also easy to call into C libraries from Java - maybe
> we can write a java client ;)
>
> It would be nice to see a little bit more detail about the actual API, like
> what does a region put look like?
>
> -Dan
>
> On Wed, Mar 25, 2020 at 8:25 AM Robert Houghton 
> wrote:
>
> > +1
> > YES.
> >
> > Having a set of clean C headers also allows for using a broad set of code
> > generators for additional languages (Swig, for example).
> >
> >
> >
> > On Tue, Mar 24, 2020 at 2:20 PM Blake Bender  wrote:
> >
> > > Hello everyone,
> > >
> > > We'd like to add C bindings to the native client, in preparation for
> the
> > > larger task of adding support for new languages, e.g. .net core.
> Please
> > > have a look at the proposal below and let me know what you think.
> > >
> > > Thanks,
> > >
> > > Blake
> > >
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library
> > >
> >
>

Re: [DISCUSS] Adding Google Analytics to our website

[Michael Oleske]

What things are we looking to learn?  Without knowing what we are
interested in learning I would be hesitant to add anything.  If we know
what we want to learn then a conversation about analytics would be more
fruitful (to me at least)

-michael


On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
wrote:

> Hi all,
>
> In promoting our project it might be valuable to get a better idea of where
> visitors on our website come from, what they look for and where we lose
> them. This should help us improve the website and learn what kind of blogs
> articles, videos etc. drive user interest to the website.
>
> To gain those insights I'd like to add Google Analytics (GA). While GA
> isn't open source, it is commonly used by other Apache projects. Apache
> Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
>
> I've heard rumors that we at some point had it on our website as well. Is
> this true? If so, why did we remove it?
>
> Thank you for your thoughts and concerns!
>

GitHub Project Board Applications API

[Michael Oleske]

Hi Devs!

I saw on github that the main geode project now has a project board (
https://github.com/apache/geode/projects/1).  I don't remember it being
discussed on the dev list.  Are some folks using it now for organization?
I'm curious how that flow works since our Jira could also be doing that
flow.  I ask cause I'm definitely one of those folks who'd like to
consolidate things closer to code (so github issues and the like).  I'm
wondering who's it is helping since we as an open source community haven't
really talked about making project boards/kanban boards all that often with
the tools we do have.

-michael

Re: GitHub Project Board Applications API

[Michael Oleske]

What are you hoping to learn from the exploration?  What hypothesis is the
experiment trying to prove/disprove?

-michael

On Fri, May 1, 2020 at 4:26 PM Nabarun Nag  wrote:

> It is just an experiment at the moment. We are researching ways of
> automating processes. It is an exploration attempt hence not being
> discussed at this point in time as we don't have all the information.
>
> Regards
> Naba
>
>
> On Fri, May 1, 2020 at 4:00 PM Michael Oleske  wrote:
>
> > Hi Devs!
> >
> > I saw on github that the main geode project now has a project board (
> > https://github.com/apache/geode/projects/1).  I don't remember it being
> > discussed on the dev list.  Are some folks using it now for organization?
> > I'm curious how that flow works since our Jira could also be doing that
> > flow.  I ask cause I'm definitely one of those folks who'd like to
> > consolidate things closer to code (so github issues and the like).  I'm
> > wondering who's it is helping since we as an open source community
> haven't
> > really talked about making project boards/kanban boards all that often
> with
> > the tools we do have.
> >
> > -michael
> >
>

Re: Over usage of @SuppressWarnings

[Michael Oleske]

For context, here is an example of PR that added warnings as error
https://github.com/apache/geode/pull/4816.  Here is the JIRA
https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7869

-michael

On Fri, May 8, 2020 at 11:45 AM Kirk Lund  wrote:

> I'm reviewing lots of PRs which are
> adding @SuppressWarnings("deprecation"), etc. I think this is a bad trend.
> We should not be suppressing warnings in our code. That's hiding a problem
> that we'll need to or want to deal with in the future. Also, if you add
> several of these suppress annotations into a class or a method or a test,
> it really diminishes the readability. It adds noise and suppresses valid
> warnings.
>
> On one of Jinmei's PRs, she responded saying she has to add these to her
> code because of some change that Jake made to the build. Can we make it so
> we don't have to add these suppressions?
>
> Thanks,
> Kirk
>

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Michael Oleske]

> Suppose I want to commit to another contributor's fork. How can they grant
> me permission to do so? (This is a common predicament for me when I'm
> reviewing doc PRs.)

Just as a note: if there is a PR and it is from a fork, the person who opens 
the PR can check a box that says "Allow contributors to commit to the PR" (or 
something like that).  That box allows anyone who is committer to commit to 
that PR regardless if it is fork.

-michael

From: Jianxia Chen 
Sent: Wednesday, June 3, 2020 17:27
To: dev@geode.apache.org 
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP 
Branches

The contributor has to add you as a collaborator of the contributor’s fork.

On Wed, Jun 3, 2020 at 5:05 PM Dave Barnes  wrote:

> Suppose I want to commit to another contributor's fork. How can they grant
> me permission to do so? (This is a common predicament for me when I'm
> reviewing doc PRs.)
>
>
> On Wed, Jun 3, 2020 at 2:04 PM Xiaojian Zhou  wrote:
>
> > We have discussed that when in Common team. The current solution worked
> > perfectly.
> >
> > One person will merge the develop into feature/GEODE-7665 (which
> > conceptually can be anyone. I did 2 times) every week. Now Naba is taking
> > the responsibility to do the weekly merge. He did great!
> >
> > Fork will cause many other issues, it will still need a person to
> maintain
> > it. I feel fork is only suitable for a work that will be finished within
> a
> > week.
> >
> > Regards
> > Gester
> >
> > On 6/2/20, 4:41 PM, "Nabarun Nag"  wrote:
> >
> > I don’t think it is right to make the open source Geode Community to
> > work on my personal fork
> >
> > Regards
> > Naba
> >
> >
> > -Original Message-
> > From: Mark Hanson 
> > Sent: Tuesday, June 2, 2020 4:35 PM
> > To: dev@geode.apache.org
> > Subject: Re: [DISCUSSION] Stop using the Geode Repository for
> > Feature/WIP Branches
> >
> > While I am not 100% sure, I understand your thoughts here, I am
> pretty
> > sure I do. We have already done such work in a branch in a fork
> (Micrometer
> > work). The only real gotcha was that there needed to be one person at
> least
> > as a collaborator, in case of vacations and such.
> >
> > All of the things you have specified are possible within the confines
> > of a fork.
> >
> > Thanks,
> > Mark
> >
> > On 6/2/20, 4:29 PM, "Nabarun Nag"  wrote:
> >
> > - We are maintaining feature/GEODE-7665 which is the feature
> > branch for PR clear work on which multiple developers are working on.
> > - We are maintaining this in Geode repository.
> > - All sub-tasks of GEODE-7665 are merged into this feature
> branch.
> > - Anyone in the Geode community can work on any subtask
> > - This is a long running, and a massive feature development which
> > is manipulating core code on Apache Geode. Hence all work is pushed to
> the
> > feature branch to keep develop isolated from a regression introduced in
> PR
> > clear work.
> > - We have previously used release flags for Lucene work which we
> > found to be inefficient and unnecessary extra work.
> >
> > We vote that PR clear feature branch be maintained in the Geode
> > Repository as this is a long running, massive effort involving everyone
> > from the community.
> >
> > When the PR clear tasks are completed, the branch will be
> > rigorously tested and then squash merged into develop and the feature
> > branch will be deleted.
> >
> >
> > Regards
> > Naba
> >
> > -Original Message-
> > From: Jacob Barrett 
> > Sent: Tuesday, June 2, 2020 3:43 PM
> > To: dev@geode.apache.org
> > Subject: [DISCUSSION] Stop using the Geode Repository for
> > Feature/WIP Branches
> >
> > I know this has been brought up multiple times without
> resolution.
> > I want us resolve to ban the use of Geode repository for work in
> progress,
> > feature branches, or any other branches that are not release or support
> > branches. There is no reason given the nature of GitHub why you can’t
> fork
> > the repository to contribute.
> >
> > * Work done on these branches results in the ASF bots updating
> the
> > associated JIRAs and email blasting all of us with your work.
> >
> > * People don’t clean up these branches, which leads to a mess of
> > branches on everyones clones and in the UI.
> >
> > * All your intermediate commits get synced to the repo, which
> > bloats the repo for everyone else. Even your commits you rebase over and
> > force push are left in the repo. When you delete your branch these
> commits
> > are not removed. There is no way for us to prune unreferenced commits.
> > Nobody else needs your commits outside of what was merged to a production
> > branch.
> >
> > If anyone has a use case for working directly from Geode repo
> that
> > can’t work from a fork plea

Re: [PROPOSAL] Postpone Geode 1.14

[Michael Oleske]

Is there plans as a community to do a postmortem or retrospective around why 
the release is taking so long?  If there is an understanding of events that 
occurred to cause the long delay of Geode 1.13 to be released, that would help 
inform decisions if processes should change or if the release cadence should 
change (or both!)

-michael

From: Xiaojian Zhou 
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Postpone Geode 1.14

+1

On 7/29/20, 1:35 PM, "Mark Bretl"  wrote:

+1

Should we need to drop a line to user@geode or is communicating on this
list enough once decided?

--Mark

On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior  wrote:

> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann"  wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>

Re: [PROPOSAL] Postpone Geode 1.14

[Michael Oleske]

I'm going to take the lack of replies as there are no plans for a retrospective 
on this.  If there is interest in doing this in the future, I'd be happy to 
facilitate the discussion.

-michael


From: Mark Hanson 
Sent: Monday, August 3, 2020 09:59
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Postpone Geode 1.14

+1 to Michael's suggestion.

On 7/31/20, 5:38 PM, "Michael Oleske"  wrote:

Is there plans as a community to do a postmortem or retrospective around 
why the release is taking so long?  If there is an understanding of events that 
occurred to cause the long delay of Geode 1.13 to be released, that would help 
inform decisions if processes should change or if the release cadence should 
change (or both!)

-michael

From: Xiaojian Zhou 
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL] Postpone Geode 1.14

+1

On 7/29/20, 1:35 PM, "Mark Bretl"  wrote:

+1

Should we need to drop a line to user@geode or is communicating on this
list enough once decided?

--Mark

On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior  
wrote:

> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann"  
wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut 
the
> 1.14
> release. The actual ship date for Geode 1.13 is important 
information
> for
> that conversation. Thus we cannot have that conversation before 
then.
>
>

State of https://github.com/apache/geode-dotnet-core-client

[Michael Oleske]

Hi Geode Dev Friends!

I'm starting a personal little side project and was thinking of using Geode as 
my backend (no real reason, certainly doesn't need the capabilities of Geode, 
but thought it'd be fun.)  I'm writing my application in .NET 5 (which is core 
based) and was going to try and use 
https://github.com/apache/geode-dotnet-core-client

I see no one has really made any changes to it for a while, and that it seems 
to have some proprietary references in it.  Is it in a usable state for simple 
puts/gets?

-michael

GEODE Jira Access

[Michael Oleske]

Hi all,

I'd like to be able to update GEODE Jira to reflect what I'm working on, so
was hoping to get access.

Thanks!
michael

Michael Oleske
Software Engineer
Pivotal - Santa Monica

Re: GEODE Jira Access

[Michael Oleske]

Just made an account. Username is mole...@pivotal.io

-michael

Michael Oleske
Software Engineer
Pivotal - Santa Monica

On Wednesday, March 21, 2018, Dan Smith  wrote:

> Hi Michael - What's your JIRA username? If you don't have one, please go
> ahead and create an account.
>
> -Dan
>
> On Wed, Mar 21, 2018 at 3:27 PM, Michael Oleske 
> wrote:
>
> > Hi all,
> >
> > I'd like to be able to update GEODE Jira to reflect what I'm working on,
> so
> > was hoping to get access.
> >
> > Thanks!
> > michael
> >
> > Michael Oleske
> > Software Engineer
> > Pivotal - Santa Monica
> >
>

Re: Instructions for Setting Up IntelliJ

[Michael Oleske]

+1 for the repo as source of truth. Wiki always seemed better as a place to
show examples rather than how to build the project.  I also like having the
readme about how to use the product and the building about how to manually
build so one could contribute (especially since Geode already provided
(unofficial) convenience binaries)

-michael

On Tuesday, September 11, 2018, Alexander Murmann 
wrote:

> +1 for putting it into the repo. I am fine with either putting it into
> README.md or linking form there.
>
> On Tue, Sep 11, 2018 at 4:33 PM, Ryan McMahon 
> wrote:
>
> > Kirk - I have a PR open here which has the "Setting up IntelliJ" section
> > you've described:
> > https://github.com/apache/geode/pull/2456
> >
> > I would be happy to use your version if you think it is more
> comprehensive,
> > or we can revise my PR to include any details you feel are missing.
> >
> > Ryan
> >
> > On Tue, Sep 11, 2018 at 4:15 PM, Jacob Barrett 
> > wrote:
> >
> > > Put it with the source! BUILDING.md or other file.
> > >
> > > > On Sep 11, 2018, at 4:11 PM, Kirk Lund  wrote:
> > > >
> > > > I don't care which location (wiki or part of the readme) but I do
> have
> > > > up-to-date instructions that I could update either location with.
> > Maybe a
> > > > detailed "Setting up IntelliJ" section on BUILDING.md? Just let me
> know
> > > if
> > > > you'd like my version.
> > > >
> > > >> On Tue, Sep 11, 2018 at 3:36 PM, Jianxia Chen 
> > > wrote:
> > > >>
> > > >> +1 to revise the wiki to link to README.md/BUILDING.md
> > > >>
> > > >> On Tue, Sep 11, 2018 at 3:22 PM Ryan McMahon <
> mcmellaw...@apache.org>
> > > >> wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> I am looking to add more comprehensive instructions for how to
> bring
> > > >> Geode
> > > >>> into IntelliJ.  I've written the instructions but am now looking at
> > > where
> > > >>> to put them.
> > > >>>
> > > >>> There appears to be duplicate information in these sections of the
> > > Geode
> > > >>> wiki and the README.md/BUILDING.md in the Geode Git repository.
> > > >>>
> > > >>>
> > > >>> https://cwiki.apache.org/confluence/display/GEODE/
> > > >> Getting+Started+for+Geode+Developers
> > > >>>
> > > >>> https://cwiki.apache.org/confluence/display/GEODE/
> > > >> Building+and+Running+Geode+from+Source
> > > >>>
> > > >>> I'm a fan of one source of truth, but I wanted to see if anyone
> felt
> > > >>> strongly about where the information lives.  I propose we revise
> the
> > > wiki
> > > >>> to simply link to the README.md/BUILDING.md and eliminate the
> > duplicate
> > > >>> information (how to run gradlew, etc).  Any thoughts?
> > > >>>
> > > >>> Thanks,
> > > >>> Ryan
> > > >>>
> > > >>
> > >
> >
>

Re: Geode Native & Apache Geode 1.8 Release

[Michael Oleske]

Plus 1 for source release. Exciting times we live in!

For verifying, plus one to a pipeline that's not just travis. Though
they're instructions in the repo about how to run tests to get that
baseline confidence.

-michael

On Wednesday, October 10, 2018, Anilkumar Gingade 
wrote:

> Good work team.
> +1 to get this as part of Geode 1.8 release.
> It will be good to see community taking advantage of this. And building new
> native client apps.
> I assume it will have all the docs about client-server compatibility
> version info. And framework for backward compatibility testing with new
> geode releases.
>
> -Anil.
>
>
>
> On Wed, Oct 10, 2018 at 12:02 PM Ernest Burghardt 
> wrote:
>
> > +1 for a source release
> >
> >
> > On Wed, Oct 10, 2018 at 12:59 PM Anthony Baker 
> wrote:
> >
> > > I think starting with a source-only release of the native client is a
> > good
> > > first step.  That lets us focus on verifying that all the tasks
> outlined
> > in
> > > [1] are complete and correct.
> > >
> > > Anthony
> > >
> > > [1] https://issues.apache.org/jira/browse/GEODE-1416
> > >
> > >
> > > > On Oct 10, 2018, at 11:52 AM, Dan Smith  wrote:
> > > >
> > > > That is awesome! Let's get it in!
> > > >
> > > > I think there are some details to work out:
> > > > - Do we need to build any automation for creating the native source
> > > > release (similar to ./gradlew srcDist on the java side)?
> > > > - Will we release binaries? Which platforms and how to does the
> release
> > > > manager build them?
> > > > - How do we verify the NC code - can we create a public pipeline?
> > > >
> > > > Shipping these native APIs will be a great improvement!
> > > >
> > > > -Dan
> > > >
> > > > On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy 
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> The Geode Native components (https://github.com/apache/geode-native
> )
> > > have
> > > >> made tremendous progress since its original donation to Apache.  The
> > > >> project is nearing a release candidate and I propose that the *first
> > > >> official release of Geode Native be included in Apache Geode 1.8.*
> > > >>
> > > >> Since donation, the project has
> > > >>
> > > >>   - modernized its C++ API based on C++ 11 standards
> > > >>   - refactored away the cache singleton to allow for more flexible
> > > >>   architectures and client-side data modeling
> > > >>   - refactored the serializable interfaces (DataSerializable,
> > > >>   PdxSerializable, DataSerializableFixedId) to make object
> > serialization
> > > >>   more straight-forward
> > > >>   - created several examples on how to use the client (
> > > >>   https://github.com/apache/geode-native/tree/develop/examples)
> > > >>
> > > >> In all, the project has closed 285 JIRA tickets since donation.
> > > >>
> > > >> If you want to learn more about the Geode Native, check out these
> two
> > > >> Apache Geode By Example videos.
> > > >>
> > > >> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4&t=3s
> > > >>
> > > >> C++: https://www.youtube.com/watch?v=KJciEcFRdtY&t=1s
> > > >>
> > > >> Looking forward to hearing your input on including the first cut of
> > > Geode
> > > >> Native in Apache Geode 1.8.
> > > >>
> > > >>
> > > >> Best,
> > > >> Addison
> > > >>
> > >
> > >
> >
>

Spotless Check failing on Windows?

[Michael Oleske]

Hi Geode Dev Friends!

I was building the latest off of develop (hash 75d7ed8a49d6) in PowerShell
on my Windows box and noticed during build that the spotless check failed.
It strangely fails on line endings (\r\n fun times) on what seems to be all
(or at least 34 of them) build.gradle files.  This seems odd to me since I
didn't realize that spotless check actually checked more than just java
files.  I assume no pipeline picked this up since the pipelines would build
once and pass the jar around rather than build on Windows and Linux (since
JVM and all that).  I haven't tracked down when this started happening to
me (though I can if that is of interest to people).

If anyone has any thoughts I'd like to hear (even if they are just why
Windows why!)

-michael

Re: Spotless Check failing on Windows?

[Michael Oleske]

I'll look to make time to play with it and open a PR/Jira if I get anywhere
useful. I only bothered with this thread since it is jarring if you are a
new dev and clone the project and the build fails on first try.

-michael

On Monday, November 12, 2018, Patrick Rhomberg  wrote:

> Spotless has only been checking our gradle for maybe a week or two.  It
> enforces dependency configurations using parentheses and single-quotes so
> they would be easier to sort while some of us made dependencies explicit.
> (Also, a future spotless improvement, once I can shake the bugs out).
>
> The issue you're hitting is exactly what the lineEndings='unix' is supposed
> to alleviate.  We specify lineEndings='unix', although looking at the
> documentation now, DiffPlug "highly recommend[s] that you do not change
> this value" from its default of GIT_ATTRIBUTES.  (This has been the case
> since shortly after its introduction in October of 2016.)
>
> You could try changing the lineEndings value to GIT_ATTRIBUTES and update
> our .gitattributes to define a less-narrowly-defined eol.  (It currently
> appears to only target *.java files.)  I don't have a Windows environment
> up and running to test this on, but if you wanted to poke at these corners,
> it's likely where the issue lives.  Otherwise, we could coerce a platform
> check into spotlessCheck.upToDateWhen so that it is skipped on Windows, but
> I'd be morally opposed to that.
>
> Imagination is Change.
> ~Patrick
>
> [1] https://github.com/diffplug/spotless/tree/master/plugin-gradle
> [2] https://help.github.com/articles/dealing-with-line-endings/
>
> On Sun, Nov 11, 2018 at 8:47 PM, Owen Nichols  wrote:
>
> > The pipeline does actually build on Windows, but with -x spotlessCheck
> >
> > Someone (maybe whoever’s touched th spotless rules most recently) might
> > know what to do. I tend to agree that the same source code ought to be
> able
> > to pass spotless on both Linux and windows; and our pipeline should
> > probably be tweaked to ensure this gets tested.
> >
> > On Sun, Nov 11, 2018 at 8:35 PM Michael Oleske 
> wrote:
> >
> > > Hi Geode Dev Friends!
> > >
> > > I was building the latest off of develop (hash 75d7ed8a49d6) in
> > PowerShell
> > > on my Windows box and noticed during build that the spotless check
> > failed.
> > > It strangely fails on line endings (\r\n fun times) on what seems to be
> > all
> > > (or at least 34 of them) build.gradle files.  This seems odd to me
> since
> > I
> > > didn't realize that spotless check actually checked more than just java
> > > files.  I assume no pipeline picked this up since the pipelines would
> > build
> > > once and pass the jar around rather than build on Windows and Linux
> > (since
> > > JVM and all that).  I haven't tracked down when this started happening
> to
> > > me (though I can if that is of interest to people).
> > >
> > > If anyone has any thoughts I'd like to hear (even if they are just why
> > > Windows why!)
> > >
> > > -michael
> > >
> >
>

Re: Spotless Check failing on Windows?

[Michael Oleske]

For those who like closure here's a PR
<https://github.com/apache/geode/pull/2873> and Geode Issue
<https://issues.apache.org/jira/browse/GEODE-6073> for a fix to the issue

-michael

On Mon, Nov 12, 2018 at 6:10 PM Michael Oleske  wrote:

> I'll look to make time to play with it and open a PR/Jira if I get
> anywhere useful. I only bothered with this thread since it is jarring if
> you are a new dev and clone the project and the build fails on first try.
>
> -michael
>
> On Monday, November 12, 2018, Patrick Rhomberg 
> wrote:
>
>> Spotless has only been checking our gradle for maybe a week or two.  It
>> enforces dependency configurations using parentheses and single-quotes so
>> they would be easier to sort while some of us made dependencies explicit.
>> (Also, a future spotless improvement, once I can shake the bugs out).
>>
>> The issue you're hitting is exactly what the lineEndings='unix' is
>> supposed
>> to alleviate.  We specify lineEndings='unix', although looking at the
>> documentation now, DiffPlug "highly recommend[s] that you do not change
>> this value" from its default of GIT_ATTRIBUTES.  (This has been the case
>> since shortly after its introduction in October of 2016.)
>>
>> You could try changing the lineEndings value to GIT_ATTRIBUTES and update
>> our .gitattributes to define a less-narrowly-defined eol.  (It currently
>> appears to only target *.java files.)  I don't have a Windows environment
>> up and running to test this on, but if you wanted to poke at these
>> corners,
>> it's likely where the issue lives.  Otherwise, we could coerce a platform
>> check into spotlessCheck.upToDateWhen so that it is skipped on Windows,
>> but
>> I'd be morally opposed to that.
>>
>> Imagination is Change.
>> ~Patrick
>>
>> [1] https://github.com/diffplug/spotless/tree/master/plugin-gradle
>> [2] https://help.github.com/articles/dealing-with-line-endings/
>>
>> On Sun, Nov 11, 2018 at 8:47 PM, Owen Nichols 
>> wrote:
>>
>> > The pipeline does actually build on Windows, but with -x spotlessCheck
>> >
>> > Someone (maybe whoever’s touched th spotless rules most recently) might
>> > know what to do. I tend to agree that the same source code ought to be
>> able
>> > to pass spotless on both Linux and windows; and our pipeline should
>> > probably be tweaked to ensure this gets tested.
>> >
>> > On Sun, Nov 11, 2018 at 8:35 PM Michael Oleske 
>> wrote:
>> >
>> > > Hi Geode Dev Friends!
>> > >
>> > > I was building the latest off of develop (hash 75d7ed8a49d6) in
>> > PowerShell
>> > > on my Windows box and noticed during build that the spotless check
>> > failed.
>> > > It strangely fails on line endings (\r\n fun times) on what seems to
>> be
>> > all
>> > > (or at least 34 of them) build.gradle files.  This seems odd to me
>> since
>> > I
>> > > didn't realize that spotless check actually checked more than just
>> java
>> > > files.  I assume no pipeline picked this up since the pipelines would
>> > build
>> > > once and pass the jar around rather than build on Windows and Linux
>> > (since
>> > > JVM and all that).  I haven't tracked down when this started
>> happening to
>> > > me (though I can if that is of interest to people).
>> > >
>> > > If anyone has any thoughts I'd like to hear (even if they are just why
>> > > Windows why!)
>> > >
>> > > -michael
>> > >
>> >
>>
>

Rescued Geode Protobuf

[Michael Oleske]

Hi Geode Friends!

Since I didn't see any movement on rescuing Geode Protobuf into another 
repository, I went ahead and did that.  It seemed like a better idea to me than 
trying to search commit history or old branches with git.  It is located at

https://github.com/moleske/geode-protobuf

I'm willing to move it into the Apache org if someone who is not lazy like me 
wants to help.  I have only upgraded to Gradle 6.8.3 and pull Geode 
dependencies from Maven as the big changes.  I add some GitHub actions for CI 
and to automatically open PRs to try and keep it up to date and working, mostly 
because I won't dedicate that much time to it.  I just really dislike seeing 
code that seemed useful get lost like that (I spend a lot of time thinking 
about how to preserve technological history.)

Anywho, hope this helps out anyone who might decide protobuf is worth spending 
time with.

-michael

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

[Michael Oleske]

Apache Hawq<https://github.com/apache/hawq/actions> uses github actions, and I 
suspect many others use it as well (from a quick search of the Apache github 
org<https://github.com/search?l=YAML&q=org%3Aapache+workflows&type=Code>).  So 
I suspect you won't have a difficult time with asf infrastructure

-michael

From: Anthony Baker 
Sent: Friday, October 7, 2022 08:53
To: dev@geode.apache.org 
Subject: Re: https://concourse.apachegeode-ci.info/ is shutting down

⚠ External Email

Sounds like good idea to me! You might check with ASF Infra to see their views 
on GF actions. If you can find another project that has already done this, it’s 
a lot easier.

Anthony


> On Oct 7, 2022, at 8:24 AM, Mario Salazar de Torres 
>  wrote:
>
> ⚠ External Email
>
> Hi everyone,
>
> Regarding this, some time ago Michael Oleske and myself were looking into 
> implementing GitHub Actions as the de-facto CI solution for Geode Native. Now 
> Concourse CI is not available anymore, I'd like to propose GH actions as the 
> alternative, at least for Geode Native.
> I have been preparing the pipelines and there are still some details to work 
> out, but it looks promising, you can check I.E this run: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNordix%2Fgeode-native%2Factions%2Fruns%2F3176127664&data=05%7C01%7Cmoleske%40vmware.com%7C3c4f7e7998e34fb7d7a608daa87c1277%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007548087651526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ir%2FILuvVcoLRsXIDWBLLOO%2FCooz2ddv7jY6NK41qBh0%3D&reserved=0
>
> So, I wanted to ask what you think about this proposal.
> My idea is if nobody presents any arguments against it by next Wednesday, 
> 12th of October, I'll start to work on it.
>
> Also, when you say ASG-hosted CIs, you mean like whole CI solutions right? Do 
> you happen to know if they provide hardware resources on its own? I mention 
> it because it would be ideal to connect GH actions to that hardware so 
> executions would take less time.
>
> /Mario
> 
> From: Anthony Baker 
> Sent: Thursday, September 29, 2022 8:32 PM
> To: dev@geode.apache.org 
> Subject: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2F&data=05%7C01%7Cmoleske%40vmware.com%7C3c4f7e7998e34fb7d7a608daa87c1277%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007548087651526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WggI7hqMvafW5ilUQXWY1Qoz0nt5PGWENmoe6gAYYqw%3D&reserved=0
>  is shutting down
>
> At 3pm PST today the 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2F&data=05%7C01%7Cmoleske%40vmware.com%7C3c4f7e7998e34fb7d7a608daa87c1277%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638007548087651526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WggI7hqMvafW5ilUQXWY1Qoz0nt5PGWENmoe6gAYYqw%3D&reserved=0
>  site will be shutting down. Apologies for the short notice, I just received 
> this information today.
>
> As discussed on other threads, there are ASF-hosted CI alternatives. I’m 
> happy to point any volunteers in the right direction.
>
>
> Anthony
>
>
> 
>
> ⚠ External Email: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender.

Re: Pullrequest required checks

[Michael Oleske]

I believe the required checks are setup in the .asf.yaml file 
here.  I would hope 
just deleting those lines would remove the existing checks and in your migrate 
to github actions pr you could change the required checks.  I would hope this 
doesn't need a vote as those current required check's pipelines seem to all 
have been removed.

-michael

From: Sai Boorlagadda 
Sent: Sunday, January 22, 2023 08:28
To: dev@geode.apache.org 
Subject: Pullrequest required checks

!! External Email

Could someone have info regarding how the required checks are enabled on a
Pull Request?

In the process of setting up the Github Actions, I see there are still
Concourse CI checks as "required" eg: on this PR[1]

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7870&data=05%7C01%7Cmoleske%40vmware.com%7C64eff0f8ae934a67e2b608dafc95eb87%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100018086696005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4w0XLfg0ks8bVEwQRYIfsl5q1CKGpXy0pAUl7KUO2io%3D&reserved=0

Thanks
Sai

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

Re: Pullrequest required checks

[Michael Oleske]

Quick addendum, it looks like you would have to update the master branch as 
well as develop.  As the master 
branch<https://github.com/apache/geode/blob/master/.asf.yaml#L39> has more 
required checks for reason.

-michael

From: Michael Oleske 
Sent: Monday, January 23, 2023 09:20
To: dev@geode.apache.org 
Subject: Re: Pullrequest required checks

!! External Email

I believe the required checks are setup in the .asf.yaml file 
here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2F.asf.yaml%23L35&data=05%7C01%7Cmoleske%40vmware.com%7Ca08669bc99d24832dd5e08dafd662876%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100912455129730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5bKCtDt7LEO1WxYwtH5rtFCch5wJzjuk6uHGx3yQ9lY%3D&reserved=0>.
  I would hope just deleting those lines would remove the existing checks and 
in your migrate to github actions pr you could change the required checks.  I 
would hope this doesn't need a vote as those current required check's pipelines 
seem to all have been removed.

-michael

From: Sai Boorlagadda 
Sent: Sunday, January 22, 2023 08:28
To: dev@geode.apache.org 
Subject: Pullrequest required checks

!! External Email

Could someone have info regarding how the required checks are enabled on a
Pull Request?

In the process of setting up the Github Actions, I see there are still
Concourse CI checks as "required" eg: on this PR[1]

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7870&data=05%7C01%7Cmoleske%40vmware.com%7Ca08669bc99d24832dd5e08dafd662876%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638100912455129730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4OndODLKhyumfbU330712kWLSgrc%2FkcGRh%2Fu4GQeLcs%3D&reserved=0

Thanks
Sai

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