Hi Xinyu, well as I would be writing the code from scratch, I would simply call the option “nodeId” and not “nodeIds” and not support any form of array type. So, it would only support single node operations by design.
But yeah … if it’s really a time-consuming operation, I agree … we should only allow one deletion at a time. Chris Von: Xinyu Tan <tanxi...@apache.org> Datum: Mittwoch, 14. August 2024 um 11:32 An: dev@iotdb.apache.org <dev@iotdb.apache.org> Betreff: Re: AW: AW: [DISCUSS] Refactor ConfigNode and DataNode to be the command-line instances? Hi, Chris In my view, removing datanodes is a careful and time-consuming task, so there's no point in making it easy to delete multiple datanodes at once, which might cause other problems. How about simply forbidding the deletion of multiple nodes at once? What do you think? Best ---------------- Xinyu Tan On 2024/08/14 08:47:56 Christofer Dutz wrote: > Hi Xinyu, > > I fully agree with all of this … especially the part where I don’t have to > update the Chinese documentation ;-) > I guess if I did that, I would have no idea if the end result was really what > I intended it to be or a recipe for dumplings ;-) > > Happy to whip up a PR based on 1.4.0-SNAPSHOT for config and data-node (I > guess it might even make sense to put the shared code in commons … this way I > can easily update the AI node to work synchronously. > > I guess from a user perspective, I guess it would make sense to possibly > update the ServerCommandLine to allow a simple “stop” or “remove” command > without any additional arguments, that simply removes the node where the code > is executed. Should we then also allow removal of multiple nodes by > supporting passing in multiple node-ids? I know the existing code indicated > that in general removing multiple nodes was planned at some time, but other > parts of the code then forced single-node removals. > > Chris > > > Von: Xinyu Tan <tanxi...@apache.org> > Datum: Mittwoch, 14. August 2024 um 10:35 > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > Betreff: Re: AW: [DISCUSS] Refactor ConfigNode and DataNode to be the > command-line instances? > Hi, Chris > > Thank you for your sharing, and I salute your ongoing passion for code > refactoring. > After studying the related code, I believe there are four tasks that need to > be done: > > * Remove xxNodeCommandLine: It seems that these classes are indeed redundant, > and their previous multi-round mutual calls with xxNode are confusing. I look > forward to your clear refactoring. > * Refactor the start-up commands of datanode and confignode using commons > cli: The concept of SBOM has been quite popular recently, and IoTDB is > currently trying to control the introduction of new dependency packages to > avoid some potential compliance risks. I checked our POM file and found that > we have already depended on commons cli, so this change will not bring new > dependency packages, and I fully support doing this, which will be much more > elegant than the current manual judgment of strings. > * Change the start and stop commands: Currently, when upgrading, we often > recommend that users update the lib directory and the sbin directory > synchronously, but I just checked the iotdb official website and did not find > any relevant documentation on upgrades. I think as long as we have > synchronized updates for all scripts, there will be no problem. I can take > charge of promoting the update of user upgrade documentation to avoid > problems when users upgrade. > * AINode: After AINode is open-sourced in the future, we need to go through > the above work again for AINode. > > What are your thoughts? > > Best > ------------- > Xinyu Tan > > On 2024/08/12 08:06:34 Christofer Dutz wrote: > > I think it’s unfortunately a bit core to many of the design-decisions being > > made in IoTDB. > > Many tasks seem to be done in too short time and quite often people are not > > taking the required “step back” in order to create a good overall > > architecture. > > I am seeing this in way too many places in the config-node and data-node > > modules. > > > > My proposal would be to completely rewrite the code for the starting and > > stopping of the data- and config nodes. This wouldn’t be as much work as it > > sounds, a I would personally base it on Apache Commons CLI. This way we > > would have a much cleaner and better tested command-line. > > > > However, the syntax would change. > > > > “DataNode -s” > > > > Would become something like: > > > > “DataNode start” > > > > And: > > > > “DataNode -r 42” > > > > Would become something like: > > > > “DateNode -nodeId 42 remove” > > > > > > Chris > > > > Von: liyuheng <liyuheng55...@126.com> > > Datum: Freitag, 9. August 2024 um 05:54 > > An: dev@iotdb.apache.org <dev@iotdb.apache.org> > > Betreff: Re: [DISCUSS] Refactor ConfigNode and DataNode to be the > > command-line instances? > > Hi Chris, > > > > I also feel that extracting separate DataNodeCommandLine and > > ConfigNodeCommandLine classes is not really necessary. > > > > When observing the DataNode startup process, although the main function is > > in DataNode, it needs to first go around to DataNodeCommandLine and then > > back to DataNode. This convoluted call process confuses me. Perhaps this is > > an attempt to separate the command line from the main class? Or maybe this > > is just a history design? > > > > Anyway, I'm looking forward to you simplifying the logic here. > > > > LiYuHeng > > > > > 2024年8月7日 22:42，Christofer Dutz <christofer.d...@c-ware.de> 写道： > > > > > > Hi all, > > > > > > while working on cleaning up on some config-node removal, I am struggling > > > a bit with the structure of our code. > > > For example, the main entry point for a program is “DataNode” and > > > “ConfigNode”, but the main methods, redirect control to a “commandline” > > > instance. > > > Depending on the command issued, the commandline then needs to reference > > > back to the same instance that called the commandLine do to some other > > > things. > > > > > > I think as both DataNode and ConfigNode only implement an mbean > > > interface, it would be cleaner to move the CLI stuff into the main > > > classes and move the stuff for starting and stopping nodes into “command” > > > implementations for the CLI? This mixture is hard to test and maintain. > > > > > > Also, could the think about basing the CLI on Apache Commons CLI, however > > > that could bring changes in output with it. > > > > > > What do you others think? > > > > > > Chris > > >
