geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrel Schneider <dschnei...@pivotal.io>
Subject Re: [DISCUSS] what region types to support in the new management rest api
Date Wed, 21 Aug 2019 00:09:19 GMT
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 <klund@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 <dschneider@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 <jiliao@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 <jdeppe@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 <mstolz@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 <
> > > dschneider@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 <jiliao@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message