geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <jil...@pivotal.io>
Subject Re: [DISCUSS] what region types to support in the new management rest api
Date Wed, 21 Aug 2019 02:29:10 GMT
And if there the old way of specifying types/shortcuts was somehow
counter-intuitive, 'cause I did from time to time, hearing things like "I
wish we did things differently", this is our chance of correcting it.

On Tue, Aug 20, 2019 at 6:47 PM Jacob Barrett <jbarrett@pivotal.io> wrote:

> If you code it you have to test it. An all or nothing approach will take
> longer to deliver any value. Breaking it into a priority set and committing
> the sets gives immediate value.
>
> > On Aug 20, 2019, at 6:12 PM, Michael Stolz <mstolz@pivotal.io> wrote:
> >
> > I'm not at all sure why supporting the current set is more work than a
> > subset. Are we planning to fix issues in the current implementation in
> the
> > new API rather than the underlying (still needed) existing API? How is
> that
> > a good idea?
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, Pivotal Cloud Cache
> > Mobile: +1-631-835-4771
> >
> >> On Tue, Aug 20, 2019, 9:09 PM Anilkumar Gingade <agingade@pivotal.io>
> wrote:
> >>
> >> 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 <dschneider@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 <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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>


-- 
Cheers

Jinmei

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