Hi all,
As discussed, the below changes have been done with [1] and [2] to
eliminate the inconsistencies that we have identified in the existing
approach.
1.
Advanced Throttling Policies
-
Modifications related to API/Product Level Throttling Policies
-
When we try to *import* an API/API Product with an Advanced
Throttling Policy which is not currently available in the API
Manager, an
error was not displayed earlier. But with [1], now you will receive an
error and the import will be failed.
-
Modifications related to Resource Level Throttling Policies
-
No changes needed to be done.
2.
Application-level Throttling Tiers/Policies
-
When we try to *import* an Application, even if the Application-level
Throttling Tier/Policy was not available in the API Manager instance, the
application was imported to that instance, which was wrong. But with [1],
now you will receive an error if you try to do that and the
import will be
failed.
3.
Subscription-level Throttling Tiers/Policies
-
When we *export* an API/API Product with a Subscription-level
Throttling Tier/Policy using the API Controller, the throttling policy
details were ncluded in the api.yaml file inside the exported
directory as an array. But now with [1] and [2], the throttling policy
names will be exported as an array instead of all the details of
tiers.
-
When we try to *import* an API/API Product, if any of the
Subscription-level Throttling Tiers/Policies were not available
in the API
Manager, the API Manager ignored it and imported the API/API Product with
the existing Subscription-level Throttling Tiers/Policies. But with [1],
now you will receive an error if you are trying to import an API/API
Product with the Subscription-level Throttling Tiers/Policies if at least
one of those are not available in the API Manager instance and the import
will be failed.
[1] https://github.com/wso2/carbon-apimgt/pull/9366
[2] https://github.com/wso2/product-apim-tooling/pull/525
Thanks,
Wasura
On Wed, Nov 4, 2020 at 12:00 PM Wasura Wattearachchi <[email protected]>
wrote:
> Hi all,
>
> I would like to add the below points to the Limitations in the Current
> Behaviour under the topics *1. Advanced Throttling Policies* and *3.
> Subscription-level Throttling Tiers/Policies*. Those inconsistencies will
> be addressed in this effort as well.
>
>
> 1.
>
> Advanced Throttling Policies
>
> We know that these can be added for an API or for a particular resource. I
> also stated in the first mail that 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. Yes, but this happens only for the
> policies added to the API resources.
>
> So the same thing should happen when we try to import an API with an
> Advanced Throttling Policy that has been assigned to the whole API, which
> is not currently available in the API Manager. Currently, an error will not
> be displayed in this scenario and this inconsistency should be fixed by
> throwing an error.
>
>
> 1.
>
> Subscription-level Throttling Tiers/Policies
>
> Here, consider the below scenario.
>
> Let’s say that I have exported an API named ABC which has the subscription
> tiers Gold, and Bronze.
>
> Next, I am trying to import that ABC API to another environment but that
> environment does not have Bronze tier.
>
> Current, behaviour of this is, that the API will be imported successfully,
> but with the Gold tier only which is confusing. IMO, this is like, even the
> API publisher has already MANDATED which subscription policies an API
> should have, if that policy is not there in that new environment, we add
> the API to that environment with those policies missing without considering
> the MANDATED Subscription-level Throttling Tiers/Policies by the publisher,
> which is wrong.
>
> This inconsistency should be fixed as well during this effort.
>
> Thanks,
>
> Wasura
>
> 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>
>>
>>
>>
>
> --
> *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>
>
>
>
--
*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
