You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Shiroshica Kulatilake <sh...@wso2.com> on 2014/08/27 04:05:50 UTC
Introducing tenant isolation in policy/definition creation and usage
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
*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.
- 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
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi,
We are planning to support manual scaling by allowing users to change
min/max of deployment policies. Therefore sometimes the user may engage one
deployment policy for one cartridge cluster or subscription. So the
subscriber need to have some control over deployment policies.
With that, the manual scaling(changing min/max) capability should be given
to subscriber, like the he get to choose the deployment policy now.
Thanks.
On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <sh...@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
>
> *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.
> - 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
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Shiroshica Kulatilake <sh...@wso2.com>.
Hi Imesh,
Yes - so if that's the case then we will have to load that specific tenant
if not already loaded (AFAIU) - and it that process seems costly - then we
will have to revert back to storing everything in super tenant space with a
tenant categorization.
Needs investigation and will be working on these aspects this week
Thank you,
Shiro
On Fri, Aug 29, 2014 at 7:32 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi,
>
> Indeed a great effort! +1
>
> A quick question on tenant based registry artifact deployment:
> As I understand Autoscaler works in super tenant space and fetch policies
> from the registry. What would be the approach we are planning to take here
> for allowing Autoscaler to read policies deployed in tenant space?
>
> Thanks
>
>
> On Tue, Aug 26, 2014 at 10:05 PM, Shiroshica Kulatilake <sh...@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
>>
>> *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.
>> - 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
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Shiroshica Kulatilake
Architect,
WSO2, Inc. http://wso2.com/
Phone: +94 776523867
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Imesh Gunaratne <im...@apache.org>.
Hi,
Indeed a great effort! +1
A quick question on tenant based registry artifact deployment:
As I understand Autoscaler works in super tenant space and fetch policies
from the registry. What would be the approach we are planning to take here
for allowing Autoscaler to read policies deployed in tenant space?
Thanks
On Tue, Aug 26, 2014 at 10:05 PM, Shiroshica Kulatilake <sh...@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
>
> *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.
> - 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
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Shiroshica Kulatilake <sh...@wso2.com>.
Hi,
Replies inline.
On Wed, Aug 27, 2014 at 4:31 PM, Akila Ravihansa Perera <ra...@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" <sh...@wso2.com> wrote:
>
>> Hi Isuru,
>>
>> Answering your questions inline.
>>
>> On Wed, Aug 27, 2014 at 12:44 PM, Isuru Haththotuwa <is...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> +1 to this effort in general.
>>>
>>> On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <sh...@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
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
Hi,
+1 for the discussed features.
What component will be responsible for quota checking for tenants?
Are there going to be any API changes?
Is the code and UIs being developed separately? At what point are we going
to merge it with master branch?
Thanks
On 27 Aug 2014 14:47, "Shiroshica Kulatilake" <sh...@wso2.com> wrote:
> Hi Isuru,
>
> Answering your questions inline.
>
> On Wed, Aug 27, 2014 at 12:44 PM, Isuru Haththotuwa <is...@apache.org>
> wrote:
>
>> Hi,
>>
>> +1 to this effort in general.
>>
>> On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <sh...@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
>
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Shiroshica Kulatilake <sh...@wso2.com>.
Hi Isuru,
Answering your questions inline.
On Wed, Aug 27, 2014 at 12:44 PM, Isuru Haththotuwa <is...@apache.org>
wrote:
> Hi,
>
> +1 to this effort in general.
>
> On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <sh...@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
Re: Introducing tenant isolation in policy/definition creation and usage
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi,
+1 to this effort in general.
On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <sh...@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?
>
> *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.
> - 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/>*
>
>
>