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: lahi...@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
