Is there a roadmap to implement the orchestration? YuanSheng Wang <[email protected]> 于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 <[email protected]> wrote: > > > That's great. > > > > Ming Wen <[email protected]> 于2020年6月21日周日 上午9:47写道： > > > > > > No, dashboard can help users to understand how to use plugins. > > > > > > agile6v <[email protected]> 于 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 <[email protected]> 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 <[email protected]> > 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 >
