Thanks for your feedback Harsha. Yes the points you have made can be valid.
The current feedback we have gotten from the team is, since an admin user is responsible for defining and updating throttle policies, supporting this via apictl is not a priority. If we do get more requests for supporting this via apictl we can take this under consideration. On Tue, 3 Nov 2020 at 16:40, Harsha Kumara <[email protected]> wrote: > I do agree that importing policies would be a one time task. But it's not > always true in general scenarios. Users should be able to update policies > and providing this support isn't hard. There can be situations which > require increasing the limits and even modify the visibility settings of > policies. If API flow is fully automated, update functionality can become > more usable. If the user modifies existing tiers? not providing update > features may become problematic. > > Ideally you should think on minimizing the use of UI or API if the user > wants a fully automated API deployment flow. > > Bulk update is a good to have feature. > > Thanks, > Harsha > > On Tue, Nov 3, 2020 at 9:59 PM Wasura Wattearachchi <[email protected]> > wrote: > >> Hi, >> >> On Tue, Nov 3, 2020 at 4:08 PM Harsha Kumara <[email protected]> wrote: >> >>> What are the plans for the updates for the policies? >>> >>> It's required to revisit this feature in the perspective of CI/CD >>> pipeline building. AFAIK APIs now can smoothly transit between the >>> environments. How this capability should work with the CI/CD pipeline also >>> should be investigated. In a CI/CD pipeline, I think it allows to change >>> the throttle policies via placeholders. >>> >> Yes, what you have stated is correct. The throttling policies can be >> changed via placeholders. But there are some limitations as explained in >> the section *Limitations in the Current Behaviour. *So our main aim is >> to address those which will ultimately smoothen the support for CI/CD. >> >> Any plans for bulk import and export the policies? I think this option >>> would be more usable in the perspective of throttling policies. >>> >> As explained before, since importing/exporting throttling policies is a >> one-time procedure per environment I don't think providing import/export >> functionality for policies as a bulk will have a significant impact. @Uvindra >> Dias Jayasinha <[email protected]> can provide more insight into this. >> >> Another concern is that policies in lower environments can be different >>> in the upper environments. Think more on how this should be addressed while >>> APIs are moving across the environments. >>> >> Yes, different environments can have different policies. So when >> importing an API, by changing the api.yaml file or swagger.yaml with the >> corresponding throttling policy(ies), the users can change the policies >> according to the environment. >> >> Thanks, >> Wasura >> >> >>> Thanks, >>> Harsha >>> >>> On Tue, Nov 3, 2020 at 4:08 PM Wasura Wattearachchi <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>> >>> >>> -- >>> *Harsha Kumara* >>> *PhD Student* >>> *LaTrobe University* >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> *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 >> > > > -- > *Harsha Kumara* > *PhD Student* > *LaTrobe University* > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
