Hi, Replies inline.
On Wed, Aug 27, 2014 at 4:31 PM, Akila Ravihansa Perera <[email protected]> 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" <[email protected]> wrote: > >> Hi Isuru, >> >> Answering your questions inline. >> >> On Wed, Aug 27, 2014 at 12:44 PM, Isuru Haththotuwa <[email protected]> >> wrote: >> >>> Hi, >>> >>> +1 to this effort in general. >>> >>> On Wed, Aug 27, 2014 at 7:35 AM, Shiroshica Kulatilake <[email protected]> >>> 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
