My vote is for supporting all the region type currently supported. As mike was pointing, we have seen usecases where different regions are used for specific application needs.
On Tue, Aug 20, 2019 at 5:09 PM Darrel Schneider <dschnei...@pivotal.io> wrote: > gfsh create region currently does not support "distributed-no-ack" nor > "global". I did not find in jira a feature request for gfsh to support > these. So I think it would be safe for the Geode Management REST API to > also not support those scopes. > > > On Tue, Aug 20, 2019 at 12:10 PM Kirk Lund <kl...@apache.org> wrote: > > > Here's my 2cents: The Geode Management REST API should definitely support > > "group" such that creation of a region may target zero, one, or more > > groups. > > > > On Tue, Aug 20, 2019 at 10:45 AM Darrel Schneider <dschnei...@pivotal.io > > > > wrote: > > > > > Is "group" support on the PCC roadmap or is the plan for the members > of a > > > cluster to always be uniform? > > > > > > On Tue, Aug 20, 2019 at 9:56 AM Jinmei Liao <jil...@pivotal.io> wrote: > > > > > > > So, sound like we still need to support *PROXY types. It's OK to drop > > > > support for LOCAL* region types in management rest API? > > > > > > > > Also, regarding existing region shortcuts, we are also experimenting > > > using > > > > different object types to represent different types of region, for > > > example, > > > > redundantCopies property should only exists in partition regions. > > Instead > > > > of having a flat object that could have a type of any of these values > > and > > > > holds all sorts of properties that may/may not make sense for that > > type, > > > > should just have a factory method that given these region shortcuts, > we > > > > would return a specific region object that's determined by this type? > > > > > > > > On Tue, Aug 20, 2019 at 8:15 AM Jens Deppe <jde...@pivotal.io> > wrote: > > > > > > > > > Currently, when deployed to the cloud (aka PCC) there is no ability > > > for a > > > > > user to group members thus it is also not possible to create > regions > > > (via > > > > > gfsh at least) that are separated by groups. Typically one would > > > create a > > > > > PROXY region against one group and the PARTITION region against > > another > > > > > group. However, without the ability to assign groups, that is not > > > > possible. > > > > > > > > > > --Jens > > > > > > > > > > On Tue, Aug 20, 2019 at 7:46 AM Michael Stolz <mst...@pivotal.io> > > > wrote: > > > > > > > > > > > I know that lots of folks use PROXY regions on the server side to > > > host > > > > > > logic associated with the region, but I think they always do that > > in > > > > > > conjunction with server groups so that the proxy is on some of > the > > > > server > > > > > > and the same region containing data is on others. Given the way > > > > cache.xml > > > > > > works they might not even bother with the server groups, but I'm > > not > > > > > sure. > > > > > > > > > > > > I think we should carry forward the existing shortcuts and not go > > > > > backward > > > > > > to the separate attributes. > > > > > > > > > > > > -- > > > > > > Mike Stolz > > > > > > Principal Engineer, Pivotal Cloud Cache > > > > > > Mobile: +1-631-835-4771 > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 19, 2019 at 7:59 PM Darrel Schneider < > > > > dschnei...@pivotal.io> > > > > > > wrote: > > > > > > > > > > > > > Keep in mind that the context of the regions in question is the > > > > > cluster. > > > > > > So > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 19, 2019 at 4:26 PM Jinmei Liao <jil...@pivotal.io > > > > > > wrote: > > > > > > > > > > > > > > > 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, > > > > > > > > PARTITION_REDUNDANT_PERSISTENT, > > > > > > > > PARTITION_OVERFLOW, > > > > > > > > PARTITION_REDUNDANT_OVERFLOW, > > > > > > > > PARTITION_PERSISTENT_OVERFLOW, > > > > > > > > PARTITION_REDUNDANT_PERSISTENT_OVERFLOW, > > > > > > > > PARTITION_HEAP_LRU, > > > > > > > > PARTITION_REDUNDANT_HEAP_LRU, > > > > > > > > > > > > > > > > REPLICATE, > > > > > > > > REPLICATE_PERSISTENT, > > > > > > > > REPLICATE_OVERFLOW, > > > > > > > > REPLICATE_PERSISTENT_OVERFLOW, > > > > > > > > REPLICATE_HEAP_LRU, > > > > > > > > > > > > > > > > REPLICATE_PROXY, > > > > > > > > PARTITION_PROXY, > > > > > > > > PARTITION_PROXY_REDUNDANT, > > > > > > > > > > > > > > > > In region management rest api, especially in PCC world, we > are > > > > > > wondering > > > > > > > > 1) should we allow users to create LOCAL* regions through > > > > management > > > > > > rest > > > > > > > > api? > > > > > > > > 2) should we allow users to create *PROXY regions through > > > > management > > > > > > rest > > > > > > > > api? > > > > > > > > 3) for the rest of the PARTITION* and REPLICATE* types, > should > > we > > > > > > strive > > > > > > > to > > > > > > > > keep the region type list the same as before, or only keep > the > > > type > > > > > as > > > > > > > > REPLICATE/PARTITION, but use other properties like > > > "redundantCopy" > > > > > and > > > > > > > > "evictionAction" to allow different permutations of region > > > > > attributes? > > > > > > > > > > > > > > > > comments appreciated! > > > > > > > > -- > > > > > > > > Cheers > > > > > > > > > > > > > > > > Jinmei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Cheers > > > > > > > > Jinmei > > > > > > > > > >
