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
