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

Reply via email to