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
