What are the plans for the updates for the policies? It's required to revisit this feature in the perspective of CI/CD pipeline building. AFAIK APIs now can smoothly transit between the environments. How this capability should work with the CI/CD pipeline also should be investigated. In a CI/CD pipeline, I think it allows to change the throttle policies via placeholders.
Any plans for bulk import and export the policies? I think this option would be more usable in the perspective of throttling policies. Another concern is that policies in lower environments can be different in the upper environments. Think more on how this should be addressed while APIs are moving across the environments. Thanks, Harsha On Tue, Nov 3, 2020 at 4:08 PM Wasura Wattearachchi <[email protected]> wrote: > Hi all, > > As per the discussion, we will be addressing only the shortcomings > mentioned in the section *Limitations in the Current Behaviour*, to make > the behaviour more consistent and user friendly. Since importing/exporting > throttling policies is a one-time procedure per environment, we decided not > to support full export/import functionality with new commands. > > Thanks, > Wasura > > On Mon, Nov 2, 2020 at 5:43 PM Uvindra Dias Jayasinha <[email protected]> > wrote: > >> +Amila De Silva <[email protected]> >> >> On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha <[email protected]> >> wrote: >> >>> >>> >>> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias <[email protected]> wrote: >>> >>>> Is the purpose of this feature to move throttling policies across >>>> environments or across product versions? >>>> >>>> Across environments >>> >>> On Mon, Nov 2, 2020 at 5:02 PM Wasura Wattearachchi <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> This is regarding the feature mentioned in [1] which requests to >>>>> support importing and exporting throttling policies using the API >>>>> Controller. Before discussing this new feature, let’s look at the >>>>> current/existing behaviour of importing/exporting throttling policies and >>>>> identify the limitations. >>>>> >>>>> Limitations in the Current Behaviour >>>>> >>>>> We have three (3) types of throttling policies. >>>>> >>>>> 1. >>>>> >>>>> Advanced Throttling Policies >>>>> >>>>> These can be added for an API or for a particular resource of an API. >>>>> >>>>> 1. >>>>> >>>>> When we export an API using the API Controller, if the Advanced >>>>> Throttling Policy was added to the whole API, then the throttling >>>>> policy name will be included in api.yaml file. >>>>> 2. >>>>> >>>>> When we export an API using the API Controller, if the Advanced >>>>> Throttling Policy was added to a particular resource, then the >>>>> throttling policy name will be included in the swagger.yaml file under >>>>> the >>>>> particular resource name. >>>>> 3. >>>>> >>>>> When the user is importing an API which was exported as mentioned >>>>> above, the Advanced Throttling Policies will be assigned to the API or >>>>> to >>>>> the resource as expected if the policy currently exists in the API >>>>> Manager >>>>> instance. >>>>> 4. >>>>> >>>>> But, if the user is importing an API with an Advanced Throttling >>>>> Policy which is not currently available in the API Manager, the import >>>>> will >>>>> fail. >>>>> >>>>> (This behaviour is ideal to handle all the types of throttling >>>>> policies which will be discussed next) >>>>> >>>>> >>>>> 1. >>>>> >>>>> Application-level Throttling Tiers/Policies >>>>> >>>>> These policies can be added for Applications. >>>>> >>>>> 1. >>>>> >>>>> When we export an Application with an Application-level Throttling >>>>> Policy using the API Controller, the throttling policy name will be >>>>> included in the <application_name>.json file inside the exported >>>>> directory. >>>>> 2. >>>>> >>>>> When the user is importing an Application which was exported as >>>>> mentioned above, the Application-level Throttling Tier/Policy will be >>>>> assigned to the Application as expected if the policy currently exists >>>>> in >>>>> the API Manager instance. >>>>> 3. >>>>> >>>>> But currently, even though the Application-level Throttling >>>>> Tier/Policy is not in the API Manager instance, the application will be >>>>> imported to that instance, which is wrong. Further, if a user login to >>>>> the >>>>> Devportal and check for the imported application, it will display an >>>>> error >>>>> as well. (The API Manager log will state that the particular >>>>> Application-level Throttling Tier/Policy is nowhere to be found) >>>>> >>>>> The behaviour of above C point should be changed and handled as stated >>>>> under the section Advanced Throttling Policies D. >>>>> >>>>> >>>>> 1. >>>>> >>>>> Subscription-level Throttling Tiers/Policies >>>>> >>>>> These policies can be added for APIs. >>>>> >>>>> 1. >>>>> >>>>> When we export an API with a Subscription-level Throttling >>>>> Tier/Policy using the API Controller, the throttling policy details >>>>> will be included in the api.yaml file inside the exported directory as >>>>> an >>>>> array (Refer the below example). >>>>> >>>>> >>>>> availableTiers: >>>>> >>>>> - >>>>> >>>>> name: MyPolicy >>>>> >>>>> displayName: MyPolicy >>>>> >>>>> description: Testing >>>>> >>>>> tierAttributes: {} >>>>> >>>>> requestsPerMin: 1 >>>>> >>>>> requestCount: 1 >>>>> >>>>> unitTime: 1 >>>>> >>>>> timeUnit: min >>>>> >>>>> tierPlan: FREE >>>>> >>>>> stopOnQuotaReached: true >>>>> >>>>> - >>>>> >>>>> name: Silver >>>>> >>>>> displayName: Silver >>>>> >>>>> description: Allows 2000 requests per minute >>>>> >>>>> requestsPerMin: 2000 >>>>> >>>>> requestCount: 2000 >>>>> >>>>> unitTime: 1 >>>>> >>>>> timeUnit: min >>>>> >>>>> tierPlan: FREE >>>>> >>>>> stopOnQuotaReached: true >>>>> >>>>> This array should contain only the names of the Subscription-level >>>>> Throttling Tiers/Policies. (In other words, this should be similar to >>>>> what happened in Advanced Throttling Policies and Application-level >>>>> Throttling Tiers/Policies wherein those scenarios only the names were >>>>> exported) >>>>> >>>>> This should be fixed. >>>>> >>>>> 1. >>>>> >>>>> When the user is importing an API which was exported as mentioned >>>>> above, the Subscription-level Throttling Tiers/Policies will be >>>>> assigned to >>>>> the API as expected if the policy exists in the API Manager instance. >>>>> This >>>>> behaviour is expected. >>>>> 2. >>>>> >>>>> But, if the user is importing an API with a Subscription-level >>>>> Throttling Tier/Policy which is not currently available in the API >>>>> Manager, >>>>> the import will fail. This behaviour is expected as well. >>>>> >>>>> >>>>> New Requirements and Features to Eliminate the Limitations >>>>> >>>>> As discussed above, the user should be able to import an API with a >>>>> particular throttling policy only if that particular policy is already >>>>> imported to that environment/instance. To facilitate this requirement, new >>>>> commands should be introduced to export/import throttling policies, prior >>>>> to export/import APIs. These commands can be in the below form. >>>>> >>>>> Command 1 >>>>> >>>>> Command >>>>> >>>>> apictl export throttling-policy [flags] >>>>> >>>>> Examples >>>>> >>>>> apictl export throttling-policy -n MyThrottlingPolicy -t advanced -e >>>>> environment >>>>> >>>>> Flags >>>>> >>>>> Mandatory >>>>> >>>>> -n, --name string Name of the >>>>> Throttling Policy to be exported >>>>> >>>>> -t, --type string Type of the >>>>> Throttling Policy (Can be advanced, application, subscription) >>>>> >>>>> -e, --environment string Environment to the which the >>>>> Throttling Policy should be imported >>>>> >>>>> Optional >>>>> >>>>> --format string File format of >>>>> exported file (default "YAML") >>>>> >>>>> Command 2 >>>>> >>>>> Command >>>>> >>>>> apictl import throttling-policy [flags] >>>>> >>>>> Example >>>>> >>>>> apictl import throttling-policy -f /home/wasura/mypolicy.yaml -t >>>>> advanced -e environment >>>>> >>>>> Flags >>>>> >>>>> Mandatory >>>>> >>>>> -f, --file string Name/Path of >>>>> the Throttling Policy to be imported >>>>> >>>>> -t, --type string Type of the >>>>> Throttling Policy (Can be advanced, application, subscription) >>>>> >>>>> -e, --environment string Environment from which the >>>>> Throttling Policy should be exported >>>>> >>>>> Optional >>>>> >>>>> --update Update an existing >>>>> Throttling Policy or create a new Throttling Policy >>>>> >>>>> REST API Requirements >>>>> >>>>> To implement the above commands in the API Controller side, REST APIs >>>>> related to the throttling policies are needed. IMO, we can use the >>>>> existing >>>>> REST APIs as explained below. >>>>> >>>>> To retrieve the throttling policy, the API Controller side can call >>>>> either of the below three (3) REST API resources in Admin V1 REST API >>>>> according to the type specified by -t (--type). Then, we can print it to a >>>>> YAML/JSON file and export/save it from the API Controller itself. >>>>> >>>>> >>>>> 1. >>>>> >>>>> To export Advanced Throttling Policies - GET >>>>> /throttling/policies/advanced >>>>> 2. >>>>> >>>>> To export Application-level Throttling Tiers/Policies - GET >>>>> /throttling/policies/application >>>>> 3. >>>>> >>>>> To export Subscription-level Throttling Tiers/Policies - GET >>>>> /throttling/policies/subscription >>>>> >>>>> >>>>> To import the throttling policy, the API Controller side can call >>>>> either of the below three (3) REST API resources in Admin V1 REST API >>>>> according to the type specified by -t (--type). >>>>> >>>>> >>>>> 1. >>>>> >>>>> To import Advanced Throttling Policies - POST >>>>> /throttling/policies/advanced >>>>> >>>>> (PUT /throttling/policies/advanced/{policyId} when the --update flag >>>>> is specified) >>>>> >>>>> 1. >>>>> >>>>> To import Application-level Throttling Tiers/Policies - POST >>>>> /throttling/policies/application >>>>> >>>>> (PUT /throttling/policies/application/{policyId} when the --update >>>>> flag is specified) >>>>> >>>>> 1. >>>>> >>>>> To import Subscription-level Throttling Tiers/Policies - POST >>>>> /throttling/policies/subscription >>>>> >>>>> (PUT /throttling/policies/subscription/{policyId} when the --update >>>>> flag is specified) >>>>> >>>>> Your feedback on the above-stated feature will be much appreciated >>>>> before starting the implementation. >>>>> >>>>> [1] https://github.com/wso2/product-apim-tooling/issues/329 >>>>> >>>>> Thank you! >>>>> -- >>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc. >>>>> (m) +94775396038 | (e) [email protected] | (b) Medium >>>>> <https://medium.com/@wasuradananjith> >>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> *Nuwan Dias* | VP and deputy CTO - API Management and Integration | >>>> WSO2 Inc. >>>> (m) +94 777 775 729 | (e) [email protected] >>>> >>> >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 777733962 >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > -- > *Wasura Wattearachchi* | Software Engineer | WSO2 Inc. > (m) +94775396038 | (e) [email protected] | (b) Medium > <https://medium.com/@wasuradananjith> > [image: http://wso2.com/signature] <http://wso2.com/signature> > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Harsha Kumara* *PhD Student* *LaTrobe University*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
