Hi, Bisakh. I'm glad to see your reply. *First of all, I think it is completely right to focus on *
*the development of dashboard's own functions. * *# remove built-in module* The reason I want to remove this built-in module is because I have recently answer many question of usage issues with this (for various reasons the Manager API does not start or stop correctly), It seems that its reliability is not good, and it is not easy to debug. *# service manager* Yes, I know there are many other service managers that make it easy for users to add adapted service files to their systems. The templates for systemd are provided because we currently provide installation files in RPM format and new versions of RHEL and CentOS systems are using systemd. Debian and Ubuntu also use it, this is the choice for most server systems used in production environments. We will build in the service file in the RPM package. For users using other systems, they can add service management functions for their own platform. For small-scale users, docker is a more convenient choice. In docker, we don't need to use service management, just run the program directly. Best regards! Zeping Bai @bzp2010 Bisakh Mondal <[email protected]> 于2021年10月26日周二 下午5:37写道： > Hi Zeping, > > Thanks for your nice proposal. But I am not sure if removing the go module > and introducing service files would be a good alternative. > The thing is that not every Unix system uses systemd as an init system > there are other service management systems like SysV, Launchd, Upstart. > Windows have a service control manager. > Now I personally think, we shouldn't write and manage the lifecycle of > multiple service files inside Manager-API as we have to continuously work > on keeping them up-to-date, fixing bugs etc. Also, this would make an > automated process (for the end-user) to a tedious manual task as after the > refactoring users need to know how to load, unload, stop service files with > that particular service manager. > > Instead, we could find a good alternative for the `takama/daemon` package > if it is not suitable for the current need. Let the respective developers > of that project handle the related problems with that package and we just > focus on improving the manager-api. > > > Thanks, > Bisakh (https://github.com/bisakhmondal) > > On Tue, 26 Oct 2021 at 10:49, Bozhong Yu <[email protected]> wrote: > > > +1. The daemon brings some other problems, for example a user unfamiliar > > with APISIX Dashboard's Manager API may install the daemon by mistake. > This > > will keep the manager-api in the OS and cannot be killed. > > > > Zeping Bai <[email protected]> 于2021年10月26日周二 下午12:16写道： > > > > > Hi, everyone. > > > > > > At present, the back end of APISIX Dashboard's Manager API uses a go > > module > > > to realize the built-in service daemon management. It is completely > > > implemented > > > by programming, which brings many use problems. > > > > > > Now, we can remove this part of the code and use the native way of > > > container or > > > systemd to manage the lifecycle of the Manager API program. Here is my > > > proposal > > > [1]. Developers interested in it can review and participate in the > > > discussion. > > > > > > [1] https://github.com/apache/apisix-dashboard/issues/2185 > > > > > > Best regards! > > > Zeping Bai @bzp2010 > > > > > >
