stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shiroshica Kulatilake <sh...@wso2.com>
Subject Re: Introducing tenant isolation in policy/definition creation and usage
Date Wed, 27 Aug 2014 23:53:02 GMT
Hi,

Replies inline.


On Wed, Aug 27, 2014 at 4:31 PM, Akila Ravihansa Perera <ravihansa@wso2.com>
wrote:

> Hi,
>
> +1 for the discussed features.
>
> What component will be responsible for quota checking for tenants?
>

So there will be two quotas to check against - the policy/definition quota
and the instance quota

The checking would be done by the components handling each of these - need
to check whether a check can be done at a earlier time so that less work is
done before "quota exceeded" is detected.

>  Are there going to be any API changes?
>
As per the design no - the json payload would differ but not the api

>  Is the code and UIs being developed separately? At what point are we
> going to merge it with master branch?
>
Yes - the new UIs and the backend change will be done in parallel - the
plan is to get this running in the mock REST endpoint so that UI won't have
to wait.

Jira is at https://issues.apache.org/jira/browse/STRATOS-761 for backend
work - there will be new jiras added for the UI work.

Will be working off a fork of master and merging in chunks which would not
break Stratos.

Hope that answers your questions :)

Thank you,
Shiro

>  Thanks
> On 27 Aug 2014 14:47, "Shiroshica Kulatilake" <shiro@wso2.com> wrote:
>
>> Hi Isuru,
>>
>> Answering your questions inline.
>>
>> On Wed, Aug 27, 2014 at 12:44 PM, Isuru Haththotuwa <isuruh@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> +1 to this effort in general.
>>>
>>> On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <shiro@wso2.com>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> In the next release(4.1.0), Stratos will have the ability to;
>>>> - define policies and definitions per tenant space
>>>> - define quotas for policies/definitions as well as quotas for actual
>>>> application creation (known as subscription now)
>>>> - make use of these within the tenant space
>>>>
>>>> This was initially mentioned in the email with the following subject.
>>>> "[Discuss] Role based access and functionality for Stratos" - the main
>>>> requirement is to provide isolation for the definitions and usage across
>>>> tenants.
>>>>
>>>> Through enabling this the following areas will get affected/updated in
>>>> the following manner.
>>>>
>>>> *1. Tenant creation for Stratos Admin (super tenant admin) - needs to
>>>> add the quotas in the carbon console. *
>>>> - There will be a payload change
>>>> - The service needs to deal with the new values sent in the payload
>>>> - These need to be persisted - in the registry
>>>> - quota definition should be for each policy/definition type and also
>>>> for each service type
>>>>
>>> What would be the payload changes that are required?
>>>
>>
>> by payload what I referred to was the json that would go to the REST
>> endpoint - we will have to have the additional quota settings in this as
>> well
>>
>>
>>>
>>>> *2. Policy creation - cartridge/MT service definition *
>>>> - There will be no payload change - the tenant ID should be obtained
>>>> from the service side
>>>> - Storage will change in the registry - currently storage happens in
>>>> the form of /_system/governance/autoscaler/partitions/Policy_name where the
>>>> separation is done via types. A tenant level needs to be added just before
>>>> the actual policy level.
>>>>
>>> Another option is to persist this information in tenant registry
>>> itself.
>>>
>>
>> Yeah - that's a good suggestion.
>> We also need the possibility of having global or public definitions - so
>> in that scenario will store these in
>> /_system/governance/public/autoscaler/partitions/Policy_name in the super
>> tenant's registry space. Any delete/update operations on this global policy
>> or definition can only be done by the owner.
>>
>>
>>
>>>  - Creation should also consider the policy/definition quotas - nice to
>>>> have would be to display on the UI how many more can be created
>>>>
>>>> *3. Usage of created policies *
>>>> - each get request should only return a list of policies/definitions
>>>> that are within the tenant space through which the call comes from
>>>> - On subscription need to consider the quota when creating the actual
>>>> instance - either need to get a count of already created and check or
>>>> maintain a counter
>>>>
>>>> *4. Migration - for existing Stratos which will be upgraded *
>>>> - all policies/definitions could be put into super tenant space -
>>>> however this would only make it possible to use these in super tenant space
>>>> after the upgrade - if there are policies / definitions that need to be
>>>> used within tenant spaces - we will have to write a generic script -
>>>> possible to have an intermediate table that would deal with the
>>>> categorization and then running migration script that would shift these to
>>>> the new structures within registry
>>>> - The quota's need to be set - for each type = current amount +
>>>> additional amount to grow into
>>>>
>>>> Any thoughts, concerns ?
>>>>
>>>> Thank you,
>>>> Shiro
>>>>
>>>> --
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> +94 716 358 048* <http://wso2.com/>*
>>>>
>>>>
>>>> * <http://wso2.com/>*
>>>>
>>>>
>>>>
>> A few more additions to the above;
>>
>> 1. The ability to have a value e.g. -1 which would indicate that there
>> are no quota's at all
>> 2. There will be no "subscription" quota - only a quota for number of
>> instances - in the case of creation of a instance as a result of
>> subscription the quota will be applicable.
>> 3. This instance quota is also something which will have to be considered
>> during autoscaling as well
>>
>>
>> Thank you,
>>  Shiro
>>
>>
>> --
>> Shiroshica Kulatilake
>>
>> Architect,
>> WSO2, Inc. http://wso2.com/
>> Phone: +94 776523867
>>
>


-- 
Shiroshica Kulatilake

Architect,
WSO2, Inc. http://wso2.com/
Phone: +94 776523867

Mime
View raw message