Hi, What about the plan progress now ?
You know, some private apis need to develop some private custom plugins. Most of us maybe do not want to change Apisix's `config.yaml` file when developing one new plugin, and do not want deploy them inside the Apisix's code. I think our custom plugins only need to export one path for Apisix, eg: `/my/custom/`. And, we can get its corresponding info: 1. `lua_package_path`, eg: `/my/custom/` ```bash # tree /my/custom/ /my/custom/ ├── plugin.yaml ├── apisix │ ├── plugins │ │ ├── filter_host.lua │ │ └── hello_grpc_auth.lua ├── stream ├── stream-plugins ├── stream1.lua └── stream2.lua ``` 2\. `plulgin.yaml`,eg:`/my/custom/plugin.yaml` And, it's content as below: ```bash # cat /my/custom/plugin.yaml plugins: # plugin list (sorted in alphabetical order) - filter_host - hello_grpc_auth stream_plugins: - stream1 - stream2 plugin_attr: hello_grpc_auth: interval: 3600 ``` We can config it in Apisix's `config.yaml`: ```yaml custom_plugins_folder: /my/custom/ ``` En, we need it. If someone has developed it, please submit a PR, or I want to submit a PR. 2021年3月4日 12:07，wei jin <[email protected]<mailto:[email protected]>> 写道： @spacewander Agree, apart from the first point of network connectivity, I did not have a good solution to the other two problems. Do other people have any good opinions ? Zexuan Luo <[email protected]<mailto:[email protected]>> 于2021年3月4日周四 上午9:33写道： The dashboard monitors the changes of the main branch and pushes the changed lua files to etcd So it means the dashboard should be able to watch the VCS of the development environment? But the network between dev environment and prod environment is either separate or unidirectional. You can push a change to the prod environment, but the prod environment can't run `git` to fetch your code. apisix(DP) automatically synchronizes the custom plugin from etcd. And do not need to write to lua file. I doubt it is suitable for debugging if we don't store it in a file. And we should remember there is a key size limitation of etcd. Etcd is not designed as a file storage. Of course, we do face some complex plug-in scenarios, for example, plug-ins that need to modify sharedict or those plugins which need to patch APISIX / OpenResty itself. I suggest that this kind of plug-in is special, so you don't need to support it at first. Only supports single lua files. A solution which only works in the normal case is unacceptable. There must be a way to extend the solution to let it work with special cases. Take opm as an example, no one uses it because it only supports pure Lua libraries. If our way only supports a single Lua file, people will switch to re-package once they need to handle special cases. So why don't they use the re-package way from the beginning?
