Hi Yann,
Thanks for bringing this into discussion.
IMHO, for the four points you mentioned above:
1) Changing the current cluster management scripts into `cluster.sh
start|stop|status` sounds good to me.
It keeps things neat and concise.
2) Moving `scp-hosts.sh`, remove-zk-node.sh`, etc. to `/tools` dir is a
good idea.
It makes those scripts more organizable and prevent users from getting
confused.
3) I think we have already had `dolphinscheduler-daemon.sh` under `bin/`
dir.
Users could use `bin/dolphinscheduler-daemon.sh start / stop xxx` to
manage each component.
4) We need more details to understand this point. Could you please submit a
new issue with details and examples?
Thanks again!
*Best Regards,*
*Chufeng (Eric) Gao*
yann ann <[email protected]> 于2022年8月23日周二 21:30写道：
> Subject: Some ideas for #11579
> Dears,
>
> First of all, thanks for Wenjun Ruan's advice, allowing me to have the
> opportunity to say some of my ideas about the issue:#11579
> <https://github.com/apache/dolphinscheduler/issues/11579>
>
> Here are some of my thoughts, please review them:
> 1) I think that the current service start, stop and service check scripts
> are not named accurately enough to convey the meaning. Could we renamed to
> start-cluster.sh、stop-cluster.sh and status-cluster.sh, or just cluster.sh
> start|stop|status.
> 2) I think it is better to store only the start、stop and status scripts of
> the cluster service in the /bin directory. Move the tool script such
> as scp-hosts.sh and remove-zk-node.sh to /tools dir. This can help users
> focus on the operation scripts of the cluster service, while shielding
> users from the tool scripts in the process.
> 3) Could we consider adding entry scripts for starting and stopping a
> single application in the /bin directory, not just
> {application}/bin/start.sh
> 4) The printing format of some log in the current script can also be more
> elegant and tidy. And i think write to a log file at the same time should
> be better for product env.
>
> Sure, personal suggestion, for reference only.
> Thanks.
>
> B. R.
> Yann
>
