You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by Ming Wen <we...@apache.org> on 2020/06/19 09:25:59 UTC
[DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Hello,
I want to discuss a new idea about plugins, and let me start by explaining
the existing plugin mechanism, plugins works according to the following
rules:
- plugins are executed after the administrator binds them to a route,
service, unless they are modified again by the admin API
- plugins are executed in order of priority which hard code
- plugins are independent of each other, the results of a plu-in will not
affect another plugin
So, some scenarios are not handled very gracefully by Apache APISIX, such
as:
- limit-count for some IPs, and others are unrestricted
- throw the failed authentication logs to kafka topic A, and others to
kafka topic B
- request which block by limit-req need to go through the fault injection
plugin
For these scenarios, we can now only handle them by creating multiple
routes, or creating new plugins.
So I think it's time to take `brain` to APISIX to orchestrate plugins. We
can add an additional plugin orchestrator without any modifications to the
existing plugins, then we can use decision tree to control plugins.
What do you think?
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by JinChao Shuai <sh...@apache.org>.
It's great, look forward to it. This will make APISXI's plugin system more
flexible and powerful.
junxu chen <ch...@apache.org> 于2020年8月29日周六 上午8:25写道：
> Sure, we have implemented the feature, and released it to our online demo.
>
> This is an example of configuration on the dashboard[1].
>
> In this example we configured a route that orchestrates `uri-blocker` and
> `fault-injection` work together.
>
> And we can verify it like this:
> ```
> curl 40.73.123.191:9080/root.exe -H "host: www.test.com" -i -w "\n
> time_total: %{time_total}\n"
> ```
>
> We could see that the request response is delayed by 2 seconds, and aborted
> with the configured status code.
>
>
>
> [1]http://139.217.190.60/routes/5c1864b7-242d-4eb0-a629-0c89d06ad609/edit
>
>
> On Fri, Aug 28, 2020 at 9:55 PM Ming Wen <we...@apache.org> wrote:
>
> > This feature has been implemented.
> > junxu, can you confirm it?
> >
> > Zexuan Luo <sp...@apache.org> 于 2020年8月28日周五 下午5:42写道：
> >
> > > Is there a roadmap to implement the orchestration?
> > >
> > > YuanSheng Wang <me...@apache.org> 于2020年7月7日周二 下午4:45写道：
> > >
> > > > 《A Technique for Drawing Directed Graphs》
> > > > http://www.graphviz.org/Documentation/TSE93.pdf
> > > >
> > > > this is useful for us. We can use this way to describe the graph
> after
> > > > plug-in orchestration.
> > > >
> > > > I will create a GitHub PR for more detail(including picture), we need
> > > more
> > > > detail to confirm the first design.
> > > >
> > > >
> > > > On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <li...@apache.org> wrote:
> > > >
> > > > > That's great.
> > > > >
> > > > > Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
> > > > > >
> > > > > > No, dashboard can help users to understand how to use plugins.
> > > > > >
> > > > > > agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > That's great.
> > > > > > >
> > > > > > > Does this mean users need to have a clear understanding of how
> > each
> > > > > plugin
> > > > > > > works?
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org>
> > > wrote:
> > > > > > > > This new way is very different from the old one.
> > > > > > > >
> > > > > > > > I love this new way.
> > > > > > > >
> > > > > > > > According to this idea, plug-ins will be more like
> > > micro-plug-ins,
> > > > > and we
> > > > > > > > can execute these micro-plug-ins one by one by way of
> > > arrangement.
> > > > > > > >
> > > > > > > > And will make these micro plug-ins become more independent
> and
> > > > > simple.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <wenming@apache.org
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > > I want to discuss a new idea about plugins, and let me
> start
> > by
> > > > > > > explaining
> > > > > > > > > the existing plugin mechanism, plugins works according to
> the
> > > > > following
> > > > > > > > > rules:
> > > > > > > > > - plugins are executed after the administrator binds them
> to
> > a
> > > > > route,
> > > > > > > > > service, unless they are modified again by the admin API
> > > > > > > > > - plugins are executed in order of priority which hard code
> > > > > > > > > - plugins are independent of each other, the results of a
> > > plu-in
> > > > > will
> > > > > > > not
> > > > > > > > > affect another plugin
> > > > > > > > >
> > > > > > > > > So, some scenarios are not handled very gracefully by
> Apache
> > > > > APISIX,
> > > > > > > such
> > > > > > > > > as:
> > > > > > > > > - limit-count for some IPs, and others are unrestricted
> > > > > > > > > - throw the failed authentication logs to kafka topic A,
> and
> > > > > others to
> > > > > > > > > kafka topic B
> > > > > > > > > - request which block by limit-req need to go through the
> > fault
> > > > > > > injection
> > > > > > > > > plugin
> > > > > > > > >
> > > > > > > > > For these scenarios, we can now only handle them by
> creating
> > > > > multiple
> > > > > > > > > routes, or creating new plugins.
> > > > > > > > >
> > > > > > > > > So I think it's time to take `brain` to APISIX to
> orchestrate
> > > > > plugins.
> > > > > > > We
> > > > > > > > > can add an additional plugin orchestrator without any
> > > > > modifications to
> > > > > > > the
> > > > > > > > > existing plugins, then we can use decision tree to control
> > > > plugins.
> > > > > > > > >
> > > > > > > > > What do you think?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > > > > > > Twitter: _WenMing
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > *MembPhis*
> > > > > > > > My GitHub: https://github.com/membphis
> > > > > > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *MembPhis*
> > > > My GitHub: https://github.com/membphis
> > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > >
> > >
> >
>
--
Thanks,
Janko
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by junxu chen <ch...@apache.org>.
Sure, we have implemented the feature, and released it to our online demo.
This is an example of configuration on the dashboard[1].
In this example we configured a route that orchestrates `uri-blocker` and
`fault-injection` work together.
And we can verify it like this:
```
curl 40.73.123.191:9080/root.exe -H "host: www.test.com" -i -w "\n
time_total: %{time_total}\n"
```
We could see that the request response is delayed by 2 seconds, and aborted
with the configured status code.
[1]http://139.217.190.60/routes/5c1864b7-242d-4eb0-a629-0c89d06ad609/edit
On Fri, Aug 28, 2020 at 9:55 PM Ming Wen <we...@apache.org> wrote:
> This feature has been implemented.
> junxu, can you confirm it?
>
> Zexuan Luo <sp...@apache.org> 于 2020年8月28日周五 下午5:42写道：
>
> > Is there a roadmap to implement the orchestration?
> >
> > YuanSheng Wang <me...@apache.org> 于2020年7月7日周二 下午4:45写道：
> >
> > > 《A Technique for Drawing Directed Graphs》
> > > http://www.graphviz.org/Documentation/TSE93.pdf
> > >
> > > this is useful for us. We can use this way to describe the graph after
> > > plug-in orchestration.
> > >
> > > I will create a GitHub PR for more detail(including picture), we need
> > more
> > > detail to confirm the first design.
> > >
> > >
> > > On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <li...@apache.org> wrote:
> > >
> > > > That's great.
> > > >
> > > > Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
> > > > >
> > > > > No, dashboard can help users to understand how to use plugins.
> > > > >
> > > > > agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > That's great.
> > > > > >
> > > > > > Does this mean users need to have a clear understanding of how
> each
> > > > plugin
> > > > > > works?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org>
> > wrote:
> > > > > > > This new way is very different from the old one.
> > > > > > >
> > > > > > > I love this new way.
> > > > > > >
> > > > > > > According to this idea, plug-ins will be more like
> > micro-plug-ins,
> > > > and we
> > > > > > > can execute these micro-plug-ins one by one by way of
> > arrangement.
> > > > > > >
> > > > > > > And will make these micro plug-ins become more independent and
> > > > simple.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I want to discuss a new idea about plugins, and let me start
> by
> > > > > > explaining
> > > > > > > > the existing plugin mechanism, plugins works according to the
> > > > following
> > > > > > > > rules:
> > > > > > > > - plugins are executed after the administrator binds them to
> a
> > > > route,
> > > > > > > > service, unless they are modified again by the admin API
> > > > > > > > - plugins are executed in order of priority which hard code
> > > > > > > > - plugins are independent of each other, the results of a
> > plu-in
> > > > will
> > > > > > not
> > > > > > > > affect another plugin
> > > > > > > >
> > > > > > > > So, some scenarios are not handled very gracefully by Apache
> > > > APISIX,
> > > > > > such
> > > > > > > > as:
> > > > > > > > - limit-count for some IPs, and others are unrestricted
> > > > > > > > - throw the failed authentication logs to kafka topic A, and
> > > > others to
> > > > > > > > kafka topic B
> > > > > > > > - request which block by limit-req need to go through the
> fault
> > > > > > injection
> > > > > > > > plugin
> > > > > > > >
> > > > > > > > For these scenarios, we can now only handle them by creating
> > > > multiple
> > > > > > > > routes, or creating new plugins.
> > > > > > > >
> > > > > > > > So I think it's time to take `brain` to APISIX to orchestrate
> > > > plugins.
> > > > > > We
> > > > > > > > can add an additional plugin orchestrator without any
> > > > modifications to
> > > > > > the
> > > > > > > > existing plugins, then we can use decision tree to control
> > > plugins.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > > > > > Twitter: _WenMing
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > *MembPhis*
> > > > > > > My GitHub: https://github.com/membphis
> > > > > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > > > > >
> > > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > *MembPhis*
> > > My GitHub: https://github.com/membphis
> > > Apache APISIX: https://github.com/apache/incubator-apisix
> > >
> >
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by Ming Wen <we...@apache.org>.
This feature has been implemented.
junxu, can you confirm it?
Zexuan Luo <sp...@apache.org> 于 2020年8月28日周五 下午5:42写道：
> Is there a roadmap to implement the orchestration?
>
> YuanSheng Wang <me...@apache.org> 于2020年7月7日周二 下午4:45写道：
>
> > 《A Technique for Drawing Directed Graphs》
> > http://www.graphviz.org/Documentation/TSE93.pdf
> >
> > this is useful for us. We can use this way to describe the graph after
> > plug-in orchestration.
> >
> > I will create a GitHub PR for more detail(including picture), we need
> more
> > detail to confirm the first design.
> >
> >
> > On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <li...@apache.org> wrote:
> >
> > > That's great.
> > >
> > > Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
> > > >
> > > > No, dashboard can help users to understand how to use plugins.
> > > >
> > > > agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> > > >
> > > > > Hi
> > > > >
> > > > > That's great.
> > > > >
> > > > > Does this mean users need to have a clear understanding of how each
> > > plugin
> > > > > works?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org>
> wrote:
> > > > > > This new way is very different from the old one.
> > > > > >
> > > > > > I love this new way.
> > > > > >
> > > > > > According to this idea, plug-ins will be more like
> micro-plug-ins,
> > > and we
> > > > > > can execute these micro-plug-ins one by one by way of
> arrangement.
> > > > > >
> > > > > > And will make these micro plug-ins become more independent and
> > > simple.
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org>
> > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > > I want to discuss a new idea about plugins, and let me start by
> > > > > explaining
> > > > > > > the existing plugin mechanism, plugins works according to the
> > > following
> > > > > > > rules:
> > > > > > > - plugins are executed after the administrator binds them to a
> > > route,
> > > > > > > service, unless they are modified again by the admin API
> > > > > > > - plugins are executed in order of priority which hard code
> > > > > > > - plugins are independent of each other, the results of a
> plu-in
> > > will
> > > > > not
> > > > > > > affect another plugin
> > > > > > >
> > > > > > > So, some scenarios are not handled very gracefully by Apache
> > > APISIX,
> > > > > such
> > > > > > > as:
> > > > > > > - limit-count for some IPs, and others are unrestricted
> > > > > > > - throw the failed authentication logs to kafka topic A, and
> > > others to
> > > > > > > kafka topic B
> > > > > > > - request which block by limit-req need to go through the fault
> > > > > injection
> > > > > > > plugin
> > > > > > >
> > > > > > > For these scenarios, we can now only handle them by creating
> > > multiple
> > > > > > > routes, or creating new plugins.
> > > > > > >
> > > > > > > So I think it's time to take `brain` to APISIX to orchestrate
> > > plugins.
> > > > > We
> > > > > > > can add an additional plugin orchestrator without any
> > > modifications to
> > > > > the
> > > > > > > existing plugins, then we can use decision tree to control
> > plugins.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > > > > Twitter: _WenMing
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > *MembPhis*
> > > > > > My GitHub: https://github.com/membphis
> > > > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > > > >
> > > > >
> > >
> >
> >
> > --
> >
> > *MembPhis*
> > My GitHub: https://github.com/membphis
> > Apache APISIX: https://github.com/apache/incubator-apisix
> >
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by Zexuan Luo <sp...@apache.org>.
Is there a roadmap to implement the orchestration?
YuanSheng Wang <me...@apache.org> 于2020年7月7日周二 下午4:45写道：
> 《A Technique for Drawing Directed Graphs》
> http://www.graphviz.org/Documentation/TSE93.pdf
>
> this is useful for us. We can use this way to describe the graph after
> plug-in orchestration.
>
> I will create a GitHub PR for more detail(including picture), we need more
> detail to confirm the first design.
>
>
> On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <li...@apache.org> wrote:
>
> > That's great.
> >
> > Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
> > >
> > > No, dashboard can help users to understand how to use plugins.
> > >
> > > agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> > >
> > > > Hi
> > > >
> > > > That's great.
> > > >
> > > > Does this mean users need to have a clear understanding of how each
> > plugin
> > > > works?
> > > >
> > > > Thanks.
> > > >
> > > > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > > > > This new way is very different from the old one.
> > > > >
> > > > > I love this new way.
> > > > >
> > > > > According to this idea, plug-ins will be more like micro-plug-ins,
> > and we
> > > > > can execute these micro-plug-ins one by one by way of arrangement.
> > > > >
> > > > > And will make these micro plug-ins become more independent and
> > simple.
> > > > >
> > > > >
> > > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org>
> wrote:
> > > > >
> > > > > > Hello,
> > > > > > I want to discuss a new idea about plugins, and let me start by
> > > > explaining
> > > > > > the existing plugin mechanism, plugins works according to the
> > following
> > > > > > rules:
> > > > > > - plugins are executed after the administrator binds them to a
> > route,
> > > > > > service, unless they are modified again by the admin API
> > > > > > - plugins are executed in order of priority which hard code
> > > > > > - plugins are independent of each other, the results of a plu-in
> > will
> > > > not
> > > > > > affect another plugin
> > > > > >
> > > > > > So, some scenarios are not handled very gracefully by Apache
> > APISIX,
> > > > such
> > > > > > as:
> > > > > > - limit-count for some IPs, and others are unrestricted
> > > > > > - throw the failed authentication logs to kafka topic A, and
> > others to
> > > > > > kafka topic B
> > > > > > - request which block by limit-req need to go through the fault
> > > > injection
> > > > > > plugin
> > > > > >
> > > > > > For these scenarios, we can now only handle them by creating
> > multiple
> > > > > > routes, or creating new plugins.
> > > > > >
> > > > > > So I think it's time to take `brain` to APISIX to orchestrate
> > plugins.
> > > > We
> > > > > > can add an additional plugin orchestrator without any
> > modifications to
> > > > the
> > > > > > existing plugins, then we can use decision tree to control
> plugins.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Thanks,
> > > > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > > > Twitter: _WenMing
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > *MembPhis*
> > > > > My GitHub: https://github.com/membphis
> > > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > > >
> > > >
> >
>
>
> --
>
> *MembPhis*
> My GitHub: https://github.com/membphis
> Apache APISIX: https://github.com/apache/incubator-apisix
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by YuanSheng Wang <me...@apache.org>.
《A Technique for Drawing Directed Graphs》
http://www.graphviz.org/Documentation/TSE93.pdf
this is useful for us. We can use this way to describe the graph after
plug-in orchestration.
I will create a GitHub PR for more detail(including picture), we need more
detail to confirm the first design.
On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <li...@apache.org> wrote:
> That's great.
>
> Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
> >
> > No, dashboard can help users to understand how to use plugins.
> >
> > agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> >
> > > Hi
> > >
> > > That's great.
> > >
> > > Does this mean users need to have a clear understanding of how each
> plugin
> > > works?
> > >
> > > Thanks.
> > >
> > > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > > > This new way is very different from the old one.
> > > >
> > > > I love this new way.
> > > >
> > > > According to this idea, plug-ins will be more like micro-plug-ins,
> and we
> > > > can execute these micro-plug-ins one by one by way of arrangement.
> > > >
> > > > And will make these micro plug-ins become more independent and
> simple.
> > > >
> > > >
> > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> > > >
> > > > > Hello,
> > > > > I want to discuss a new idea about plugins, and let me start by
> > > explaining
> > > > > the existing plugin mechanism, plugins works according to the
> following
> > > > > rules:
> > > > > - plugins are executed after the administrator binds them to a
> route,
> > > > > service, unless they are modified again by the admin API
> > > > > - plugins are executed in order of priority which hard code
> > > > > - plugins are independent of each other, the results of a plu-in
> will
> > > not
> > > > > affect another plugin
> > > > >
> > > > > So, some scenarios are not handled very gracefully by Apache
> APISIX,
> > > such
> > > > > as:
> > > > > - limit-count for some IPs, and others are unrestricted
> > > > > - throw the failed authentication logs to kafka topic A, and
> others to
> > > > > kafka topic B
> > > > > - request which block by limit-req need to go through the fault
> > > injection
> > > > > plugin
> > > > >
> > > > > For these scenarios, we can now only handle them by creating
> multiple
> > > > > routes, or creating new plugins.
> > > > >
> > > > > So I think it's time to take `brain` to APISIX to orchestrate
> plugins.
> > > We
> > > > > can add an additional plugin orchestrator without any
> modifications to
> > > the
> > > > > existing plugins, then we can use decision tree to control plugins.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks,
> > > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > > Twitter: _WenMing
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *MembPhis*
> > > > My GitHub: https://github.com/membphis
> > > > Apache APISIX: https://github.com/apache/incubator-apisix
> > > >
> > >
>
--
*MembPhis*
My GitHub: https://github.com/membphis
Apache APISIX: https://github.com/apache/incubator-apisix
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by Linsir Wu <li...@apache.org>.
That's great.
Ming Wen <we...@apache.org> 于2020年6月21日周日 上午9:47写道：
>
> No, dashboard can help users to understand how to use plugins.
>
> agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
>
> > Hi
> >
> > That's great.
> >
> > Does this mean users need to have a clear understanding of how each plugin
> > works?
> >
> > Thanks.
> >
> > On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > > This new way is very different from the old one.
> > >
> > > I love this new way.
> > >
> > > According to this idea, plug-ins will be more like micro-plug-ins, and we
> > > can execute these micro-plug-ins one by one by way of arrangement.
> > >
> > > And will make these micro plug-ins become more independent and simple.
> > >
> > >
> > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> > >
> > > > Hello,
> > > > I want to discuss a new idea about plugins, and let me start by
> > explaining
> > > > the existing plugin mechanism, plugins works according to the following
> > > > rules:
> > > > - plugins are executed after the administrator binds them to a route,
> > > > service, unless they are modified again by the admin API
> > > > - plugins are executed in order of priority which hard code
> > > > - plugins are independent of each other, the results of a plu-in will
> > not
> > > > affect another plugin
> > > >
> > > > So, some scenarios are not handled very gracefully by Apache APISIX,
> > such
> > > > as:
> > > > - limit-count for some IPs, and others are unrestricted
> > > > - throw the failed authentication logs to kafka topic A, and others to
> > > > kafka topic B
> > > > - request which block by limit-req need to go through the fault
> > injection
> > > > plugin
> > > >
> > > > For these scenarios, we can now only handle them by creating multiple
> > > > routes, or creating new plugins.
> > > >
> > > > So I think it's time to take `brain` to APISIX to orchestrate plugins.
> > We
> > > > can add an additional plugin orchestrator without any modifications to
> > the
> > > > existing plugins, then we can use decision tree to control plugins.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > > Twitter: _WenMing
> > > >
> > >
> > >
> > > --
> > >
> > > *MembPhis*
> > > My GitHub: https://github.com/membphis
> > > Apache APISIX: https://github.com/apache/incubator-apisix
> > >
> >
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by Ming Wen <we...@apache.org>.
No, dashboard can help users to understand how to use plugins.
agile6v <ag...@apache.org> 于 2020年6月20日周六 下午7:31写道：
> Hi
>
> That's great.
>
> Does this mean users need to have a clear understanding of how each plugin
> works?
>
> Thanks.
>
> On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > This new way is very different from the old one.
> >
> > I love this new way.
> >
> > According to this idea, plug-ins will be more like micro-plug-ins, and we
> > can execute these micro-plug-ins one by one by way of arrangement.
> >
> > And will make these micro plug-ins become more independent and simple.
> >
> >
> > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> >
> > > Hello,
> > > I want to discuss a new idea about plugins, and let me start by
> explaining
> > > the existing plugin mechanism, plugins works according to the following
> > > rules:
> > > - plugins are executed after the administrator binds them to a route,
> > > service, unless they are modified again by the admin API
> > > - plugins are executed in order of priority which hard code
> > > - plugins are independent of each other, the results of a plu-in will
> not
> > > affect another plugin
> > >
> > > So, some scenarios are not handled very gracefully by Apache APISIX,
> such
> > > as:
> > > - limit-count for some IPs, and others are unrestricted
> > > - throw the failed authentication logs to kafka topic A, and others to
> > > kafka topic B
> > > - request which block by limit-req need to go through the fault
> injection
> > > plugin
> > >
> > > For these scenarios, we can now only handle them by creating multiple
> > > routes, or creating new plugins.
> > >
> > > So I think it's time to take `brain` to APISIX to orchestrate plugins.
> We
> > > can add an additional plugin orchestrator without any modifications to
> the
> > > existing plugins, then we can use decision tree to control plugins.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > Twitter: _WenMing
> > >
> >
> >
> > --
> >
> > *MembPhis*
> > My GitHub: https://github.com/membphis
> > Apache APISIX: https://github.com/apache/incubator-apisix
> >
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by junxu chen <ch...@apache.org>.
It is awesome !
It will make APISIX more powerful.
Looking forward to it.
On Sat, Jun 20, 2020 at 7:31 PM agile6v <ag...@apache.org> wrote:
> Hi
>
> That's great.
>
> Does this mean users need to have a clear understanding of how each plugin
> works?
>
> Thanks.
>
> On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > This new way is very different from the old one.
> >
> > I love this new way.
> >
> > According to this idea, plug-ins will be more like micro-plug-ins, and we
> > can execute these micro-plug-ins one by one by way of arrangement.
> >
> > And will make these micro plug-ins become more independent and simple.
> >
> >
> > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> >
> > > Hello,
> > > I want to discuss a new idea about plugins, and let me start by
> explaining
> > > the existing plugin mechanism, plugins works according to the following
> > > rules:
> > > - plugins are executed after the administrator binds them to a route,
> > > service, unless they are modified again by the admin API
> > > - plugins are executed in order of priority which hard code
> > > - plugins are independent of each other, the results of a plu-in will
> not
> > > affect another plugin
> > >
> > > So, some scenarios are not handled very gracefully by Apache APISIX,
> such
> > > as:
> > > - limit-count for some IPs, and others are unrestricted
> > > - throw the failed authentication logs to kafka topic A, and others to
> > > kafka topic B
> > > - request which block by limit-req need to go through the fault
> injection
> > > plugin
> > >
> > > For these scenarios, we can now only handle them by creating multiple
> > > routes, or creating new plugins.
> > >
> > > So I think it's time to take `brain` to APISIX to orchestrate plugins.
> We
> > > can add an additional plugin orchestrator without any modifications to
> the
> > > existing plugins, then we can use decision tree to control plugins.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > Twitter: _WenMing
> > >
> >
> >
> > --
> >
> > *MembPhis*
> > My GitHub: https://github.com/membphis
> > Apache APISIX: https://github.com/apache/incubator-apisix
> >
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by YuanSheng Wang <me...@apache.org>.
On Sat, Jun 20, 2020 at 7:31 PM agile6v <ag...@apache.org> wrote:
> Hi
>
> That's great.
>
> Does this mean users need to have a clear understanding of how each plugin
> works?
>
Of course we need it. ^_^
>
> Thanks.
>
> On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> > This new way is very different from the old one.
> >
> > I love this new way.
> >
> > According to this idea, plug-ins will be more like micro-plug-ins, and we
> > can execute these micro-plug-ins one by one by way of arrangement.
> >
> > And will make these micro plug-ins become more independent and simple.
> >
> >
> > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> >
> > > Hello,
> > > I want to discuss a new idea about plugins, and let me start by
> explaining
> > > the existing plugin mechanism, plugins works according to the following
> > > rules:
> > > - plugins are executed after the administrator binds them to a route,
> > > service, unless they are modified again by the admin API
> > > - plugins are executed in order of priority which hard code
> > > - plugins are independent of each other, the results of a plu-in will
> not
> > > affect another plugin
> > >
> > > So, some scenarios are not handled very gracefully by Apache APISIX,
> such
> > > as:
> > > - limit-count for some IPs, and others are unrestricted
> > > - throw the failed authentication logs to kafka topic A, and others to
> > > kafka topic B
> > > - request which block by limit-req need to go through the fault
> injection
> > > plugin
> > >
> > > For these scenarios, we can now only handle them by creating multiple
> > > routes, or creating new plugins.
> > >
> > > So I think it's time to take `brain` to APISIX to orchestrate plugins.
> We
> > > can add an additional plugin orchestrator without any modifications to
> the
> > > existing plugins, then we can use decision tree to control plugins.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Ming Wen, Apache APISIX & Apache SkyWalking
> > > Twitter: _WenMing
> > >
> >
> >
> > --
> >
> > *MembPhis*
> > My GitHub: https://github.com/membphis
> > Apache APISIX: https://github.com/apache/incubator-apisix
> >
>
--
*MembPhis*
My GitHub: https://github.com/membphis
Apache APISIX: https://github.com/apache/incubator-apisix
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and flexibility between plugins
Posted by agile6v <ag...@apache.org>.
Hi
That's great.
Does this mean users need to have a clear understanding of how each plugin works?
Thanks.
On 2020/06/20 02:12:02, YuanSheng Wang <me...@apache.org> wrote:
> This new way is very different from the old one.
>
> I love this new way.
>
> According to this idea, plug-ins will be more like micro-plug-ins, and we
> can execute these micro-plug-ins one by one by way of arrangement.
>
> And will make these micro plug-ins become more independent and simple.
>
>
> On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
>
> > Hello,
> > I want to discuss a new idea about plugins, and let me start by explaining
> > the existing plugin mechanism, plugins works according to the following
> > rules:
> > - plugins are executed after the administrator binds them to a route,
> > service, unless they are modified again by the admin API
> > - plugins are executed in order of priority which hard code
> > - plugins are independent of each other, the results of a plu-in will not
> > affect another plugin
> >
> > So, some scenarios are not handled very gracefully by Apache APISIX, such
> > as:
> > - limit-count for some IPs, and others are unrestricted
> > - throw the failed authentication logs to kafka topic A, and others to
> > kafka topic B
> > - request which block by limit-req need to go through the fault injection
> > plugin
> >
> > For these scenarios, we can now only handle them by creating multiple
> > routes, or creating new plugins.
> >
> > So I think it's time to take `brain` to APISIX to orchestrate plugins. We
> > can add an additional plugin orchestrator without any modifications to the
> > existing plugins, then we can use decision tree to control plugins.
> >
> > What do you think?
> >
> > Thanks,
> > Ming Wen, Apache APISIX & Apache SkyWalking
> > Twitter: _WenMing
> >
>
>
> --
>
> *MembPhis*
> My GitHub: https://github.com/membphis
> Apache APISIX: https://github.com/apache/incubator-apisix
>
Re: [DISUCSS] Plugins Orchestration: Increased collaboration and
flexibility between plugins
Posted by YuanSheng Wang <me...@apache.org>.
This new way is very different from the old one.
I love this new way.
According to this idea, plug-ins will be more like micro-plug-ins, and we
can execute these micro-plug-ins one by one by way of arrangement.
And will make these micro plug-ins become more independent and simple.
On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <we...@apache.org> wrote:
> Hello,
> I want to discuss a new idea about plugins, and let me start by explaining
> the existing plugin mechanism, plugins works according to the following
> rules:
> - plugins are executed after the administrator binds them to a route,
> service, unless they are modified again by the admin API
> - plugins are executed in order of priority which hard code
> - plugins are independent of each other, the results of a plu-in will not
> affect another plugin
>
> So, some scenarios are not handled very gracefully by Apache APISIX, such
> as:
> - limit-count for some IPs, and others are unrestricted
> - throw the failed authentication logs to kafka topic A, and others to
> kafka topic B
> - request which block by limit-req need to go through the fault injection
> plugin
>
> For these scenarios, we can now only handle them by creating multiple
> routes, or creating new plugins.
>
> So I think it's time to take `brain` to APISIX to orchestrate plugins. We
> can add an additional plugin orchestrator without any modifications to the
> existing plugins, then we can use decision tree to control plugins.
>
> What do you think?
>
> Thanks,
> Ming Wen, Apache APISIX & Apache SkyWalking
> Twitter: _WenMing
>
--
*MembPhis*
My GitHub: https://github.com/membphis
Apache APISIX: https://github.com/apache/incubator-apisix