Hi, Chris Looking forward to your code!
Best ------------- Xinyu Tan On 2024/08/14 11:03:17 Christofer Dutz wrote: > 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 <[email protected]> > Datum: Mittwoch, 14. August 2024 um 11:32 > An: [email protected] <[email protected]> > 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 <[email protected]> > > Datum: Mittwoch, 14. August 2024 um 10:35 > > An: [email protected] <[email protected]> > > 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 <[email protected]> > > > Datum: Freitag, 9. August 2024 um 05:54 > > > An: [email protected] <[email protected]> > > > 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 <[email protected]> 写道： > > > > > > > > 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 > > > > > >
