Suggest to Migrate Target command to top level

[ivan-burazin]

Is your feature request related to a problem? Please describe. I have found a few issues with target being a subcommand of server:

• Lack of visibility: as a new user, I didn't know that target exists.
• It's not clear how server is connected to target.
• It seems that the target command and its subcommands: set, list, remove, are used more often than server (which is used mainly just once). Because of this, the commands become very long, which is not the best user experience.

Describe the solution you'd like My suggestion would be for target to become a top-level command: daytona target.

[Tpuljak]

The target command was on the "root" level before but we moved it because of a conversation we had on #297.

To address your concerns:

• Lack of visibility: This will be improved with #453 where the subcommands of each command (e.g. server provider and server target will be visible in the help command. Also, it's clearly stated in our readme that the target command is under server.
• It's not clear how server is connected to target. The server is what manages the targets and uses them to provide information to the provider on how to create a workspace. The main reason that target was moved under server was because of the confusion where targets "live". Because we have remote profiles, it's confusing if targets are part of your local CLI config or are they part of the server. The same principal applies to providers. They are managed by the server and "live" there so if you have a remote profile connected to another server, you won't have the same targets and providers available as your local server, for example.

Lastly,

It seems that the target command and its subcommands: set, list, remove, are used more often than server (which is used mainly just once). Because of this, the commands become very long, which is not the best user experience.

Targets are also not something the user will touch a lot. Especially if someone else manages the server for the user. We shouldn't concern ourselves if the commands are long. The main thing we need to concern ourselves is do the commands make sense and are they causing confusion.

[ivan-burazin]

This is the confusion: The main reason that target was moved under server was because of the confusion where targets "live".

Second Targets are also not something the user will touch a lot. Especially if someone else manages the server for the user. this is not true, you will always have to set your targets personally

[vedranjukic]

I don't agree with "targets are part of the server context". Everything is a part of the server context except profiles. Going forward we might have a use for the remote profile where the user will not have access to the server management. But still the targets are the feature the user will have to use. At least to list available targets.

[vedranjukic]

After additional analysis, my thoughts on this topic are that I agree with @ivan-burazin on all three points. Having a server command as a context wrapper is an unnecessary typing effort. Moreover, let's move other commands to the top level except the server process commands (stop/restart, configure, logs).