+1 to Anthony's suggestion
From: Donal Evans
Date: Wednesday, June 29, 2022 at 10:46 AM
To: dev@geode.apache.org
Subject: Re: CODEOWNERS? (was Re: Pending PR reviews)
⚠ External Email
+1 to Anthony's suggestion
I strongly supported the idea behind CODEOWNERS when it was originally
>Does this inactivity demonstrate maturity (i.e. maybe we should remove the
>@Experimental annotation) or does it indicate a failed or abandoned experiment
Neither, I believe k8s is using the feature, but the inactivity simply means we
haven’t allocated people to work on it.
From: Owen Nichols
+1
From: Nabarun Nag
Date: Wednesday, December 15, 2021 at 11:00 AM
To: dev@geode.apache.org
Subject: Re: [VOTE] Apache Geode 1.14.2.RC1
+1 to 1.14.2.RC1
* Build from source
* WAN clusters with SSL
* puts/gets
* validate data integrity after rolling restart.
Regards
Nabarun
+1
From: Nabarun Nag
Date: Wednesday, December 15, 2021 at 10:34 AM
To: dev@geode.apache.org
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.13.6.RC1
+1 to 1.13.6.RC1
* Build from source
* WAN clusters with SSL
* puts/gets
* validate data integrity after rolling restart.
+1
From: Nabarun Nag
Date: Wednesday, December 15, 2021 at 10:11 AM
To: dev@geode.apache.org
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.7.RC1
+1 to 1.12.7.RC1
* Build from source
* WAN clusters with SSL
* puts/gets
* validate data integrity after rolling restart.
My understanding is @VisibileForTesting methods are used by the products, while
@TestOnly methods are used only by the tests.
In practice, I don’t like to add @TestOnly methods (although I like to mark
those methods with this annotation if I found out a method is only used for
testing for
the "register interests and CQ"? Is that by
unregistering or queueing?
I think this RFC looks good.
Thanks,
Mark
On 7/27/21, 2:26 PM, "Jinmei Liao" wrote:
Calling more feedback on this RFC. I will move this to “Under Development”
if no objection to its general direction
Please leave the feature branch “expireAuthentication”, The RFC is in:
https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication
From: Owen Nichols
Date: Sunday, August 1, 2021 at 1:01 AM
To: dev@geode.apache.org
Subject: Annual branch
Calling more feedback on this RFC. I will move this to “Under Development” if
no objection to its general direction end of this Thursday.
Thanks!
From: Jinmei Liao
Date: Thursday, July 22, 2021 at 5:37 PM
To: dev@geode.apache.org
Subject: [discus] RFC for Geode Authentication Expiation and Re
Hi, Fellow devs,
Here the feature proposal for the said topic. Please review and provide your
feedback. Thanks!
https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication
Jinmei
itten more like a how-to.
So given the feature is still in progress. Do you want feedback on the
writing of the document or the architecture of the underlying code or both?
From: Jinmei Liao
Sent: Tuesday, November 10, 2020 10:06
To: dev@geode.
,
John
From: Jinmei Liao
Sent: Monday, October 26, 2020 10:53 AM
To: dev@geode.apache.org
Subject: How to add a new REST end point in Cluster Management Service
Hi, Geode developers,
I just added a twiki page detailing how to add a new REST
+1
On Oct 27, 2020 3:00 PM, Donal Evans wrote:
+1
From: Anthony Baker
Sent: Tuesday, October 27, 2020 2:53 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] backport GEODE-8651 to 1.13, 9.10, 9.9
+1 from me
> On Oct 27, 2020, at 2:21 PM, Xiaojian Zhou
Hi, Geode developers,
I just added a twiki page detailing how to add a new REST end point in Cluster
Management Service to manage new entities or start new long running operations
in Geode Cluster. Feel free to look it through and provide comments/suggestions.
I would like to include the fix for GEODE-8574 to 1.13.1, it would greatly help
the Geode on k8s experience.
Thanks!
Jinmei
we even need a
classification scheme? IOW, why not just take what the user gives us and say
thank you :-). Is this restriction imposed by our *implementation* choices?
Anthony
> On Oct 7, 2020, at 3:24 PM, Jinmei Liao wrote:
>
> Wait, t
Wait, that reason doesn't make much sense either. Dale/Darrel, do you remember
why we did what we did?
On 10/7/20, 3:12 PM, "Jinmei Liao" wrote:
I believe we did this for a reason, can't remember exactly what though.
Most probably drive by user's existing filenames. I
I believe we did this for a reason, can't remember exactly what though. Most
probably drive by user's existing filenames. I believe we are probably
concerned that user's jar name might contain "_" or "-" themselves, like
common-logging.jar etc. So we had to resort to finding the first "."
+1
Verified geode management rest urls are working as expected.
On 9/8/20, 9:53 AM, "Owen Nichols" wrote:
+1
I have reviewed test results for a battery of internal functional and
performance tests, reviewed the LICENSE file for accuracy, looked at the logs
for all checks in the rc
+1
On 8/19/20, 10:25 AM, "Xiaojian Zhou" wrote:
This problem also exists in 1.13.
+1
On Aug 1, 2020 10:30 PM, Owen Nichols wrote:
This issue was present since Geode 1.0. There is zero risk from this fix,
which is already on develop. It is critical because Geode releases are a legal
Act of the Apache Foundation and should not misrepresent the identity of the
project.
+1
On Jul 22, 2020 3:39 PM, Dave Barnes wrote:
I propose back-porting the following doc updates to Geode support/1.13 (and
1.12, while we're at it):
- GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove from
docs (code fixed in 1.9.0, docs fixed in 1.14.0)
- GEODE-7628: Block
I would like to propose to cherry pick GEODE-8331: allow GFSH to connect to
other versions of cluster (#5375) to support branches up to 1.10. This would
allow gfsh to connect to other versions of cluster and provide better error
messages when command is not support by the connected cluster.
+1
From: Owen Nichols
Sent: Tuesday, June 30, 2020 3:56 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches
+1
On 6/30/20, 3:51 PM, "Xiaojian Zhou" wrote:
Customer encountered a singlehop getAll failure due to
I would vote for fixing the tests to use gradle's normal forking. If we are
going to invest time and effort, let's invest in an option that can reduce our
dependencies
From: Jacob Barrett
Sent: Tuesday, June 30, 2020 11:30 AM
To: dev@geode.apache.org
Subject:
+1, yay to doc changes.
From: Dave Barnes
Sent: Monday, June 29, 2020 10:30 AM
To: dev@geode.apache.org
Subject: [Proposal] Back-port doc fixes to support/1.13
These five doc changes correct doc bugs and format errors that have caused
users pain. I propose that
+1, what was the reason for it not being included the PR before?
From: Dick Cavender
Sent: Thursday, June 25, 2020 9:54 AM
To: dev@geode.apache.org
Subject: RE: [PROPOSAL] Add windows jobs to PR checks
+1
-Original Message-
From: Owen Nichols
Sent:
In the old management team, we have been considering the idea of getting rid of
jmx connection in gfsh and only using http connection mechanism.
On Jun 19, 2020 2:53 PM, Jacob Barrett wrote:
So I can see why this research paper was so bleak about the options in trying
to get the SSL
Need one more vote
From: Bruce Schuchardt
Sent: Thursday, June 18, 2020 3:43 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] back port fix for GEODE-8251 to support branches
+1
On 6/18/20, 3:24 PM, "Jinmei Liao" wrote:
The fix for this is
The fix for this issue https://issues.apache.org/jira/browse/GEODE-8251 is
needed on support 1.13 branch in order for rolling upgrade to work from 1.12 to
1.13.
Thanks!
Jinmei
+1 for making it simpler for upgrade.
From: Owen Nichols
Sent: Monday, June 15, 2020 1:41 PM
To: dev@geode.apache.org
Subject: Re: Refactor to Restore Redundancy Command for 1.13?
There is precedent[1] for bringing a refactoring to a support branch prior to
+1 for ban the use of geode repo for feature branches. Less clutter is better.
From: Jacob Barrett
Sent: Tuesday, June 2, 2020 3:42 PM
To: dev@geode.apache.org
Subject: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches
I know this has been
quest message to the grantor. The cost is with sending message to the
Grantor, in most cases. Which is not bad, considering the configuration does
not change frequently.
-Anil.
On 5/28/20, 11:08 AM, "Jinmei Liao" wrote:
Simultaneous updates to configurations are already protected by a diffe
ter a period of time?
Anthony
> On May 28, 2020, at 10:17 AM, Jinmei Liao wrote:
>
> The proposal is proposing using ONE single dlock to synchronize all CMS CRUD
> operations, that means, in a given time, only one CRUD operation in CMS is
> allowed in the entire cluster, this see
ID element. That way, we allow more concurrency. I am just not sure what's
the cost of creating a dlock. Is the the cost of creating a dlock per ID
warrants the performance gain?
Comment/Suggestions?
Jinmei
From: Jinmei Liao
Sent: Tuesday, May 26, 2020 1:02 PM
Hi, Geode Community,
Currently, the CMS CRUD operations are not thread safe, if one call tries to
create a region, and another call tries to delete the same region, if timing is
off, we could end up with inconsistent state (what's in cluster config and
what's actually on the server). So we
+1
From: Owen Nichols
Sent: Tuesday, May 26, 2020 4:09 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12
+1
On 5/26/20, 4:04 PM, "Eric Shu" wrote:
+1
From: Udo Kohlmeyer
branch, but would like an opportunity to edit for a few
> > > proof-readerish items that caught my eye. Will submit a PR today for
> your
> > > review, Jinmei. Thanks for your contribution!
> > > >
> > > > On 2020/05/20 14:09:05, Joris Melchior wrote:
>
+1
On Tue, May 19, 2020 at 10:05 AM Udo Kohlmeyer wrote:
> +1
> On May 19, 2020, 8:53 AM -0700, Bruce Schuchardt ,
> wrote:
> While investigating a distributed hang we discovered that the alerting
> system was blocking the logging of critical information that would have
> helped diagnose the
This is to update documentation to better explain the Cluster management
service and various geode/system properties that control the behavior of
it. It also provides more usage examples in the documentation. There is no
product code change in this, but tt would be helpful to the users who would
https://issues.apache.org/jira/browse/GEODE-8091
We've had users that were trying to use the
"--load-cluster-configuration-from-dir=true" when starting up a locator
with a security manager and came across this failure on Geode1.12 and would
this to be fixed. Can I get a few +1s to port this back
It's not the test code, it's the "start locator" command itself.
On Fri, May 8, 2020 at 2:27 PM Jacob Barrett wrote:
>
> > On May 8, 2020, at 1:55 PM, Jinmei Liao wrote:
> >
> > What's the recommendation for the legitimate usage of the deprecated
> > pro
What's the recommendation for the legitimate usage of the deprecated
property? In my case, a gemFire property is deprecated, but "start locator"
command still has an option to turn on that property (the option is
deprecated as well, but we are still obligated to keep it in the code). In
this case,
+1
On Thu, May 7, 2020 at 9:26 AM Donal Evans wrote:
> +1
>
> From: Dick Cavender
> Sent: Thursday, May 7, 2020 8:52 AM
> To: dev@geode.apache.org
> Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13
>
> +1
>
> On Thu, May 7, 2020 at 7:47 AM
+1
On Wed, May 6, 2020 at 11:40 AM Owen Nichols wrote:
> +1 to fix this NPE on support/1.13 and also support/1.12
>
> > On May 6, 2020, at 11:19 AM, Eric Shu wrote:
> >
> > GEODE-8073
>
>
--
Cheers
Jinmei
I would like to include the fix for GEODE-8055 in the 1.12 support branch.
This would allow users to use gfsh to create an index on sub regions.
--
Cheers
Jinmei
t; > > was sent. +1 from me to go ahead and bring to support/1.13 on that
> > basis.
> > >
> > > > On May 4, 2020, at 7:43 PM, Jinmei Liao wrote:
> > > >
> > > > Yes, there is a user request to reinstate this feature.
> > > >
> > > > O
nt to get this in 1.13.
>
> -Anil.
>
>
> On Mon, May 4, 2020 at 11:55 AM Jinmei Liao wrote:
>
> > I would like to include the fix for GEODE-8055 in the 1.13 branch. This
> > would allow users to use gfsh to create an index on sub regions.
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
I would like to include the fix for GEODE-8055 in the 1.13 branch. This
would allow users to use gfsh to create an index on sub regions.
--
Cheers
Jinmei
It failed on my PR as well.
On Fri, May 1, 2020 at 9:23 AM Kirk Lund wrote:
> I don't see anything obvious in the test so I’m going to mark the test
> @Ignore until I have a fix. Please review:
> https://github.com/apache/geode/pull/5038
>
> On Fri, May 1, 2020 at 9:00 AM Kirk Lund wrote:
>
>
1. create the revert PR ASAP
2. work on the fix properly and create the fix PR
3. wait and merge whichever goes green and approved first.
On Wed, Apr 29, 2020 at 7:13 PM Joris Melchior wrote:
> Recent experience makes me lean towards quick revert as well. Takes the
> pressure off when trying to
+1
On Fri, Apr 24, 2020 at 2:53 PM Anthony Baker wrote:
> +1
>
> > On Apr 24, 2020, at 2:46 PM, Dale Emery wrote:
> >
> > During the cleanup of the gradle build and logging, the Pulse webapp
> lost its slf4j implementation. As a result, Pulse stopped writing log files.
> >
> > I’ve restored
+1 to backport
On 4/6/20, 9:14 AM, "Anthony Baker" wrote:
+1 to backport
> On Apr 6, 2020, at 8:54 AM, Owen Nichols wrote:
>
> Recently some Geode users have expressed concern that shiro-1.4.1.jar is
getting flagged for critical security vulnerability CVE-2020-1957.
So the "restore redundancy" command is blocking and only returns when the
operation is finished?
On 3/30/20, 2:21 PM, "Kirk Lund" wrote:
[I added this as a comment on the wiki page]
You might want to consider making RestoreRedundancyOperation actually
extend
Hi everyone,
I would like to summarize what the management REST GET request would return
if the entity exists in multiple groups. The linked RFC[1] has all the
details.
[1]
https://cwiki.apache.org/confluence/display/GEODE/Group+Configuration+in+Management+Rest+API
--
Cheers
Jinmei
Have you tried running all the changed tests in your IDEA repeatedly to see
if there would be a failure?
On Wed, Mar 4, 2020 at 1:28 PM Eric Shu wrote:
> My PR (https://github.com/apache/geode/pull/4709) continue to fail in
> stressNewTest. I have been retrigger the test and all failed with
+1
On Thu, Feb 13, 2020, 6:47 AM Owen Nichols wrote:
> +1
>
> On Thu, Feb 13, 2020 at 3:38 AM Ju@N wrote:
>
> > Hello devs,
> >
> > I'd like to include the fix for GEODE-7756 [1] in release 1.12.0.
> > The change prevents a performance degradation introduced in Geode 1.11
> > through to the
+1
On Thu, Feb 13, 2020, 6:47 AM Owen Nichols wrote:
> +1
>
> On Thu, Feb 13, 2020 at 3:05 AM Nabarun Nag wrote:
>
> > +1
> >
> > On Thu, Feb 13, 2020 at 2:09 AM Ju@N wrote:
> >
> > > Hello devs,
> > >
> > > I'd like to include the fix for GEODE-7789 [1] in release 1.12.0.
> > > The change
+1
On Tue, Feb 11, 2020, 11:39 AM Udo Kohlmeyer wrote:
> +1
>
> On 2/11/20 11:23 AM, Dick Cavender wrote:
> > This regression was introduced when the geode-gfsh subproject was
> recently
> > added. While not obvious this created a critical build / runtime cycle
> > between geode-core and
+1
On Fri, Feb 7, 2020 at 8:58 AM Bruce Schuchardt
wrote:
> +1
>
> On 2/7/20, 8:36 AM, "Jinmei Liao" wrote:
>
> Hi devs,
>
> I would like to include the fix for GEODE-7717[1] in release 1.12.0.
> The
> change modifies the json response struct
+1
On Fri, Feb 7, 2020 at 9:06 AM Owen Nichols wrote:
> +1
>
> On Fri, Feb 7, 2020 at 9:04 AM Udo Kohlmeyer wrote:
>
> > +1
> >
> > On 2/7/20 8:57 AM, Bruce Schuchardt wrote:
> > > af8307 fixes a number of problems with auto-reconnect that have been
> > reported recently. Owen and Darrel did
Hi devs,
I would like to include the fix for GEODE-7717[1] in release 1.12.0. The
change modifies the json response structure of all of the "list" operations
in cluster management rest service. Including it in this release, where
most users are just starting to experiment with CMS rest service
Even though the management service is still marketed as "experimental" and
we don't need to go through deprecations, I would still very much prefer
this gets pulled into 1.12 so that users don't have to deal with
experimental public API changes.
On Wed, Feb 5, 2020 at 4:23 PM Udo Kohlmeyer
+1
On Wed, Feb 5, 2020 at 2:36 PM John Blum wrote:
> +1
>
> On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson >
> wrote:
>
> > +1
> >
> > On 2/5/20, 1:53 PM, "Udo Kohlmeyer" wrote:
> >
> > Hi there Geode dev,
> >
> > I would like to request that GEODE-7752
> >
I just reverted a commit that I made last Friday, Please also include this
commit "16b296a4" in the release branch. Thanks!
On Mon, Feb 3, 2020 at 11:07 AM Ernest Burghardt
wrote:
> Hello Geode Dev Community,
>
> We have created a new release branch for Apache Geode 1.12.0 -
> "release/1.12.0"
Is there a specific test that would cause this NPE? I will try to take a
look at it.
On Fri, Jan 10, 2020 at 9:08 AM Kirk Lund wrote:
> I think this may only occur in tests that perform a reconnect of the
> Locator.
>
> On Fri, Jan 10, 2020 at 9:06 AM Kirk Lund wrote:
>
> > Anyone know why we
+1
On Wed, Jan 8, 2020 at 7:31 PM Robert Houghton wrote:
> +1
>
> On Wed, Jan 8, 2020, 12:39 Jacob Barrett wrote:
>
> > Please see RFC for Logging to Standard Out.
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
> > <
>
Having the stressTest reuse the JVMs is close to running the tests in my
IDEA repeatedly for N times or running a package of tests together in my
IDEA. There was a time that I couldn't run a group of tests together in my
IDEA until I had to fix the problem for the stressTest. Keeping them
running
he term "usability" because
> > users expect "status server --host=xxx --port=xxx" to also work IF we
> > continue to provide "status locator --host=xxx --port=xxx". We need to
> get
> > rid of and avoid these weird quirks and inconsistencies.
> >
on-SSL-enabled client to an SSL-enabled locator.
> > >
> > >
> > > It would seem very weird if I have to provide additional connection
> > params
> > > to the 'status' command if I've already provided them as part of the
> > > 'connect'. Could we not st
tests now pass
> > >>>>> reliably but I was very frustrated by the process.
> > >>>>>> On 12/19/19 4:49 PM, Jacob Barrett wrote:
> > >>>>>>> I’m in agreement with Dan. Changes to the infrastructure to flat
>
lanket restriction. In fact I think our
> release
> > >> process involves some merges.
> > >>
> > >> I think setting standards on what is reasonable to be an individual
> > commit
> > >> will do a lot more to clean up our history than blocking
uent usage?
>
> --Jens
>
> On Wed, Dec 18, 2019 at 9:04 AM Jinmei Liao wrote:
>
> > "status locator" command is broken on ssl enabled locators ever since we
> > fixed a bug that leaked the connection properties from one tcp socket
> > connection to
+1
On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote:
> I’d like to advance this topic from an informal request/discussion to a
> discussion of a concrete proposal.
>
> To recap, it sounds like there is general agreement that commit history on
> develop should be linear (no merge commits), and
"status locator" command is broken on ssl enabled locators ever since we
fixed a bug that leaked the connection properties from one tcp socket
connection to another. Before that it would just magically work if we have
previously made a successfully tcp connection to that same locator, now we
are
+100. Would be a great move.
On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe wrote:
> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode
; same question. [the process won't take more than 30 min, also its good to
> confirm that the revert won't turn the pipeline red]
> I am more worried that how a commit that made the pipeline red made it into
> the codebase.
>
> Regards
> Naba
>
> On Thu, Oct 31, 2019 at 2:37 PM
+1
On Thu, Oct 31, 2019, 3:30 PM Xiaojian Zhou wrote:
> I'm curious to see the new stressNew test result too.
>
> On Thu, Oct 31, 2019 at 3:26 PM Owen Nichols wrote:
>
> > I’ve retriggered StressNew <
> >
>
I am not sure whether this is related to this topic or not, but recently I
had to revert one of my commit, before I could just do a revert and push to
develop, but now that is blocked. I had to file a PR to revert a change
that's causing the pipeline to be red. My question is: do we still need to
+1
On Tue, Oct 29, 2019, 6:08 PM Owen Nichols wrote:
> +1 …this has already bitten me a few times
>
> > On Oct 29, 2019, at 6:01 PM, Dan Smith wrote:
> >
> > Hi all,
> >
> > It seems we've configured our branch protection rules such that pushing a
> > change to a PR that has been approved
+1
On Tue, Oct 22, 2019 at 11:47 AM Dave Barnes wrote:
> +1
> Downloaded, successfully built Geode and Geode-Native docs form source.
>
> On Tue, Oct 22, 2019 at 2:17 AM Ju@N wrote:
>
> > +1,
> >
> > Downloaded and built from source, created two clusters with multiple
> > members and verified
ity to recognize a HTTP
> authentication header containing 'Bearer ' and
> then handing that to the Security Manager to do with as it pleases?
>
> We're not doing anything with actual token management? (i.e. generating,
> revoking, etc.).
>
> --Jens
>
> On Fri, Oct 4, 2019 at 10:59 A
Hi, all
JWT token based authentication support is added to Geode develop branch.
Currently only management v2 rest api can use this (we can add dev rest
there too if requested). In order to turn on token based auth for
management rest api, you will need to do these two things:
1. start your
> > On Wed, Sep 25, 2019 at 8:39 AM Anthony Baker wrote:
> >
> >> Sounds good, thanks for the heads up.
> >>
> >> Anthony
> >>
> >>
> >>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao wrote:
> >>>
> >>> Mana
+1 verified the management v2 apis are available.
On Mon, Sep 23, 2019 at 12:58 PM Anthony Baker wrote:
> +1
>
>
> Reviewed:
>
> - Signatures and hashes
> - LICENSE and NOTICE
> - No binaries in source distribution
> - Builds from source
>
>
> Quibbles:
>
> - Let’s include geode-benchmarks/
+ 1 verified the management v2 api is available by default and list of rest
end points.
On Fri, Aug 30, 2019 at 2:06 PM Dick Cavender wrote:
> Hello Geode dev community,
>
> This is a release candidate for Apache Geode, version 1.10.0.RC1.
> Thanks to all the community members for their
:07 AM, Alexander Murmann >
> > > wrote:
> > > >
> > > > Hey folks, I want to make sure that any other's product's roadmaps
> have
> > > no
> > > > impact on any decisions we make about Apache Geode.
> > > >
> > > > Thanks!
> > &g
>>
> >>>
> >>>> On Tue, Aug 20, 2019 at 12:10 PM Kirk Lund wrote:
> >>>>
> >>>> Here's my 2cents: The Geode Management REST API should definitely
> >> support
> >>>> "group" such that creation of a
; > > these regions would be created on servers.
> > > So, for example, does anyone see a need to create PROXY regions on the
> > > server? Even if we did not support them on the server, they would still
> > be
> > > supported on clients.
> > >
&
Region type (in another word Region shortcut) defines a set of attributes
for a region. These are the list of region types we have:
LOCAL,
LOCAL_PERSISTENT,
LOCAL_HEAP_LRU,
LOCAL_OVERFLOW,
LOCAL_PERSISTENT_OVERFLOW,
PARTITION,
PARTITION_REDUNDANT,
PARTITION_PERSISTENT,
I believe it's realistic to assume that
On Mon, Jul 22, 2019, 3:58 PM Alexander Murmann wrote:
> Jinmei,
>
> Do you think it's realistic to add the property this week and still cut the
> branch at the end of this week?
>
> On Mon, Jul 22, 2019 at 3:38 PM Jinmei Liao wrote:
&
Work is still being planned to move the cluster management rest service
under an experimental version flag and use a geode property to turn it
on/off. I would say we are ready to cut the geode 1.10.0 after that work is
complete.
On Mon, Jul 22, 2019 at 3:24 PM Alexander Murmann
wrote:
> Hi
I added the comment on this issue: Geode region names ARE case sensitive.
Should not fix.
On Mon, Jul 15, 2019 at 10:51 AM Alex Grisham wrote:
> Hello everyone,
>
> I’ve recently gotten into the Geode community and have been looking for a
> good place to start contributing. I found this Jira
They will be public API, currently, mainly used by the
ClusterManagementServivice to configure the cluster.
On Wed, Jul 10, 2019 at 9:06 PM Jacob Barrett wrote:
> Are these new objects public API or internal?
>
> > On Jul 10, 2019, at 1:16 PM, Jinmei Liao wrote:
> >
>
We've been working on a new and improved ClusterManagmentService for a
while now. It allows developers/administrators to manage the clusters
through rest calls instead of having to use gfsh (more info here:
https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
).
Up until
I agree with Murtuza, most finals on local variables and method parameters
are just noise to me. I only use "final" on these two situations:
1. to declare public static constants of immutable types (e.g. String,
Integer)
2. to prevent children from overriding a method.
But thought I can't offer
ing those settings as well, or just having a global
> > property that is the default value if it is not overridden for a specific
> > locator, cache-server, or gateway-receiver?
> >
> > -Dan
> >
> > On Tue, Jun 4, 2019 at 12:02 PM Jinmei Liao wrote:
> >
> &
We have "jmx-manager-hostname-for-clients" in the geode properties, we
think it would be a good idea to deprecate that and use
"hostname-for-clients" for the entire server. Currently we already need
this property when launching a locator and start a gateway-receiver, and we
have no way to
+1 for initial PR needs to be a single commit
+1 for making intermittent commits to the PR to show history of revision.
I would only do a rebase and force-push if github tells me that there is a
conflict, but my rebase would keep my original commits (no squashing). I do
not like to do a merge,
I was told that screenshot that I sent earlier got filtered out by the dev
list. Basically, the filter puts "notificati...@github.com" in the "From"
section, and put "review_reques...@noreply.github.com" in the "Doesn't
have" section of the form.
On Fri, May 31, 2019 at 10:36 AM Anthony Baker
1 - 100 of 656 matches
Mail list logo
