Just catching up on this thread so take it FWIW. The “new management API” is intended to become the one-and-only way to configure the system. That means that eventually cache.xml, gfsh, existing API’s, etc. will only be able to configure features supported by this new API. I think the implication is that if a feature is NOT supported by the v2 API, it effectively doesn’t exist and might as well be removed from the product itself. For gfsh in particular, I assume we’ll want to switch it over to use the new REST endpoints. The configuration points supported by those endpoints need to be congruent with gfsh (or we change gfsh).
Of course, we can always sequence work into small chunks and deliver incrementally instead of all-at-once. Anthony > On Aug 21, 2019, at 3:52 PM, Darrel Schneider <dschnei...@pivotal.io> wrote: > > Given the current types that gfsh supports, I don't see that it will be > lots of validation. We have the redundancy level to validate for the > REDUNDANT types. And we have HEAP_LRU and OVERFLOW to validate. That is it. > The only other thing is the partition only attributes should be rejected > when creating a replicate. I think we should just support the types "gfsh > create region" does. > > On Tue, Aug 20, 2019 at 7:50 PM Jinmei Liao <jil...@pivotal.io> wrote: > >> Maybe to clarify what I said before (which was certainly unclear ), I am >> not saying we only allow users to create limited set of types of region, we >> COULD still support all of them, but we should not limit ourselves to the >> current ways of doing things. Currently, a flat model of region >> configuration which holds a type and all the possible attributes any type >> of region can have, could lead to these problems: >> 1. the type may be contradictory/redundant to a particular property: >> for example, the type could "PARTITION_REDUNDANT", but the >> redundantCopies is set to be 0. And the type could be "PARTITION_OVERFLOW", >> but the eviction action is set to be "LOCAL_DESTROY". To avoid this, we >> will need to do a lot of front end validation in order to accept this >> configuration, which is possible to do, but is it really necessary? Should >> we somehow limit the type to something that really indicate the "type" >> instead of just a shortcut that actually sets a set of attributes. >> >> 2. the object can hold lots of unnecessary attributes that only pertains to >> a particular type >> for example, redundantCopies doesn't really apply to replicate regions, but >> it's there for you to configure. >> >> Just some more food for thought. >> >> >> >> >> On Tue, Aug 20, 2019 at 7:34 PM Charlie Black <cbl...@pivotal.io> wrote: >> >>> Yes it is common for 0,1 and 2. 3 enters into gray space of is the cost >>> of redundancy worth it. >>> >>> So voting for exposing the number of copies to be the same as Apache >> Geode >>> Java API. >>> >>> Charlie >>> >>> 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 >>>>>>>> >>>>>>> >>>>> >>>> >>> -- >>> Charlie Black | cbl...@pivotal.io >>> >> >> >> -- >> Cheers >> >> Jinmei >>
