+1 to the proposal with the modified rule and favoring region creation with
shortcuts.

On Fri, Feb 2, 2018 at 1:56 PM, Jinmei Liao <jil...@pivotal.io> wrote:

> I think we allowed too many ways for the user to do the same thing again.
>
> if we put in this restriction, this command would fail and user has to use
> PARTITION_PROXY type to create an accessor region, which is not a bad thing
> after all.
>
> So now, the rule is:
>
> 1. when user creates a non-proxy region (no matter on what group, what
> type), a region with the same name can not exist already in the cluster
> 2. When user creates a proxy region, a region with the same name has to
> exist on the cluster first.
>
> would this be a reasonable rule to enforce when creating regions using
> gfsh?
>
>
> On Feb 2, 2018 12:02 PM, "Sai Boorlagadda" <sai.boorlaga...@gmail.com>
> wrote:
>
>> I dont think allowing *_PROXY types with same names is sufficient. Users
>> can also create accessor regions by setting 'local-max-memory' for a
>> partition region (though not allowed for a replicate).
>>
>> gfsh>create region --name=test --type=PARTITION --local-max-memory=0
>>     Member      | Status
>> --------------- | ------------------------------------------
>> yell-gifted-cow | Region "/test" created on "server1"
>>
>> Here /test becomes an accessor region just like when created using the
>> shortcut "PARTITION_PROXY".
>>
>> On Fri, Feb 2, 2018 at 11:46 AM, Jinmei Liao <jil...@pivotal.io> wrote:
>>
>>> Accessor region is probably a special case. Then can we add this caviar
>>> then: "user can not create a region with the same name of a different type
>>> except it's a proxy region"?
>>>
>>> On Fri, Feb 2, 2018 at 11:17 AM, Sai Boorlagadda <
>>> sai.boorlaga...@gmail.com> wrote:
>>>
>>>> Agree with Dan. This is the only way I know that you can create
>>>> accessor regions on peer members.
>>>>
>>>> On Fri, Feb 2, 2018 at 11:07 AM, Dan Smith <dsm...@pivotal.io> wrote:
>>>>
>>>>> Won't this break any use case were two members need to create the same
>>>>> region with different attributes? For example someone might have some
>>>>> members that are empty accessors of a replicated region:
>>>>>
>>>>> //Host data on members in group1
>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1
>>>>>
>>>>> //Group2 just needs access to data in region A
>>>>> gfsh> create region --name=A --type=REPLICATE_PROXY --group=group2
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Fri, Feb 2, 2018 at 10:19 AM, Jinmei Liao <jil...@pivotal.io>
>>>>> wrote:
>>>>>
>>>>>> Currently creating region with the same name on different groups are
>>>>>> allowed by gfsh. Checks are done further on the servers when creating the
>>>>>> region to see if the region attributes clashes with any existing region,
>>>>>> and the operation will fail if types are different. Here is an example
>>>>>> about this current behavior:
>>>>>>
>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1  //
>>>>>> success
>>>>>>
>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2  //
>>>>>> success
>>>>>>
>>>>>> gfsh> create region --name=A --type=PARTITION --group=group2
>>>>>> --skip-if-exists  // skipping
>>>>>>
>>>>>> Member  | Status
>>>>>>
>>>>>> ------- | -----------------------------------------------
>>>>>>
>>>>>> server2 | Skipping "server2". Region "/A" already exists.
>>>>>>
>>>>>>
>>>>>> gfsh>create region --name=A --type=PARTITION --group=group3
>>>>>> --skip-if-exists // failure
>>>>>>
>>>>>> Member  | Status
>>>>>>
>>>>>> ------- | ------------------------------
>>>>>> ------------------------------------------------------------
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> server3 | ERROR: Cannot create PartitionedRegion /A because another
>>>>>> cache (10.118.33.243(server2:43156)<v4>:1026) has the same region
>>>>>> defined as a non PartitionedRegion.
>>>>>>
>>>>>> We would like to propose catching the name clash earlier in gfsh for
>>>>>> the last command as well. Since regions are referred to by names in the
>>>>>> entire cluster (no server grouping considered at all), when trying to
>>>>>> create a region, we should check for name clash in the entire cluster, 
>>>>>> not
>>>>>> just in the specified server group. If we make this change, the behavior
>>>>>> would be like this:
>>>>>>
>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1  //
>>>>>> success
>>>>>>
>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2  // Error
>>>>>>
>>>>>> ERROR: Region "/A" already exists.
>>>>>>
>>>>>>
>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2
>>>>>> --skip-if-exists // skipping
>>>>>>
>>>>>> Skipping: Region "/A" already exists.
>>>>>>
>>>>>> gfsh> create region --name=A --type=PARTITION --group=group2
>>>>>> --skip-if-exists
>>>>>>
>>>>>> Skipping. Region "/A" already exists.
>>>>>>
>>>>>> gfsh> create region --name=A --type=PARTITION --group=group3
>>>>>> --skip-if-exists
>>>>>> Skipping. Region "/A" already exists.
>>>>>>
>>>>>>
>>>>>> Basically, the name clash check is on the entire cluster, not just on
>>>>>> one specific server. This would lead to some change in script behavior, 
>>>>>> but
>>>>>> keep the command simple and consistent.
>>>>>>
>>>>>> Any feedback is welcome.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Jinmei
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>>

Reply via email to