By far the most common region "scope" is distributed-ack. We think LOCAL scope is hardly ever used. Partitioned regions ignore the scope and automatically use "distributed-ack".
Should the default scope of "distributed-no-ack" be supported by the rest management api for replicates? Should the scope of "global" be supported by the rest management api for replicates? On Tue, Aug 20, 2019 at 11:38 AM Darrel Schneider <dschnei...@pivotal.io> wrote: > The shortcuts support partitioned regions with 0 and 1 redundant copies. > Is redundancies greater than 1 common enough for the rest management api to > support it? > > On Tue, Aug 20, 2019 at 11:27 AM Jacob Barrett <jbarr...@pivotal.io> > wrote: > >> +1 to Alexander’s statement. >> >> Also, initial revisions need not be feature parity. For us on the common >> use cases. It’s sounds like an advanced use case to have proxy regions on >> the server so focus on the common partitioned and replicated first for the >> initial release. >> >> -jake >> >> > On Aug 20, 2019, at 11:07 AM, Alexander Murmann <amurm...@apache.org> >> 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! >> > >> > 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 >> >>> >> >> >> >
