I don't think updating is a very hard task to incorporate with this feature. With a -u flag, users can decide to update a policy or not. If the flow is completely automated, users shouldn't consider of using UI to perform any update which should be the end goal of a full CI/CD pipeline via apictl.
On Wed, Nov 4, 2020 at 4:10 PM Uvindra Dias Jayasinha <[email protected]> wrote: > 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 > -- *Harsha Kumara* *PhD Student* *LaTrobe University*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
