Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 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 > 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. >> >>
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 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 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 >> wrote: >> >>> Hi, >>> >>> On Tue, Nov 3, 2020 at 4:08 PM Harsha Kumara 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 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 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 < > uvin...@wso2.com> wrote: > >> +Amila De Silva >> >> On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha >> wrote: >> >>> >>> >>> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 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 .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:
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 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 > wrote: > >> Hi, >> >> On Tue, Nov 3, 2020 at 4:08 PM Harsha Kumara 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 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 >>> 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 wrote: > +Amila De Silva > > On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha > wrote: > >> >> >> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 >>> 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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 wrote: > Hi, > > On Tue, Nov 3, 2020 at 4:08 PM Harsha Kumara 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 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 >> 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 >>> wrote: >>> +Amila De Silva On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha wrote: > > > On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 >> 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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
Hi, On Tue, Nov 3, 2020 at 4:08 PM Harsha Kumara 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 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 > 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 >> wrote: >> >>> +Amila De Silva >>> >>> On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha >>> wrote: >>> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 > 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 .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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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. Any plans for bulk import and export the policies? I think this option would be more usable in the perspective of throttling policies. 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. Thanks, Harsha On Tue, Nov 3, 2020 at 4:08 PM Wasura Wattearachchi 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 > wrote: > >> +Amila De Silva >> >> On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha >> wrote: >> >>> >>> >>> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 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 .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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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
wrote:
> +Amila De Silva
>
> On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha
> wrote:
>
>>
>>
>> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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
>>> 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 .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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
+Amila De Silva
On Mon, 2 Nov 2020 at 17:42, Uvindra Dias Jayasinha
wrote:
>
>
> On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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
>> 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 .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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
On Mon, 2 Nov 2020 at 17:36, Nuwan Dias 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 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 .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
Re: [Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
Is the purpose of this feature to move throttling policies across
environments or across product versions?
On Mon, Nov 2, 2020 at 5:02 PM Wasura Wattearachchi 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 .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
[Architecture] [APIM] Support to Import/Export Throttling Policies Using the API Controller
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 .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
