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" <[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 >
