Is the purpose of this feature to move throttling policies across environments or across product versions?
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]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
