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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
