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

Reply via email to