You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the addition of the multi-proxy configuration, there have been some undesirable alterations to the behavior of the cli.
Feedback is welcome on these suggestions
Undesireable changes
A public key can only be specified via flag, not as argument
-- We should accept the public key to connect to as an argument as well as via flag
a single running instance of the proxy can't be stopped with skywire-cli proxy stop
-- If there is only one instance of the proxy running, that instance should be stopped
-- If there is more than one instance running, the default instance should be stopped.
-- If there are more than one running instance and neither is the default, then error / prompt to use --all or --name (or --pk or pk as arg)
should also be able to specify a public key to proxy stop instead of just name because the previously run command which started the proxy can just be edited to stop it
-- proxy stop should work as well with the as argument
Additionally, I suggest a flag such as --auto for starting multiple instances of the proxy, and which will start them on different ports, counting up from port 1080, skipping any already bound port.
skywire-cli proxy start --auto <pk1> <pk2> <pk3>
the naming convention should be automatic as well, and perhaps numbered instead of named ; else just use the first and last few characters of the public key.
A note on the config
any proxy which is started is written to the config by the visor API.
If it was actually written there by the cli and the config was watched by the visor, that would be one thing, but it doesn't make a lot of sense if you want to start 100 proxies to have them all be configured in the visor's config. It's more of a configuration at runtime when starting a proxy, though the way we have it currently it's possible to manually configure autostart.
This is something we will need to figure out a better solution for going forward, but I don't have a suggestion to address that currently.
i can only state that no change to the config which is made currently persists updates, on linux. See the package documentation wiki article for details on this.
The text was updated successfully, but these errors were encountered:
With the addition of the multi-proxy configuration, there have been some undesirable alterations to the behavior of the cli.
Feedback is welcome on these suggestions
Undesireable changes
-- We should accept the public key to connect to as an argument as well as via flag
skywire-cli proxy stop
-- If there is only one instance of the proxy running, that instance should be stopped
-- If there is more than one instance running, the default instance should be stopped.
-- If there are more than one running instance and neither is the default, then error / prompt to use --all or --name (or --pk or pk as arg)
proxy stop
instead of just name because the previously run command which started the proxy can just be edited to stop it--
proxy stop
should work as well with the as argument@mrpalide what do you think of this?
Possible improvements
Additionally, I suggest a flag such as
--auto
for starting multiple instances of the proxy, and which will start them on different ports, counting up from port 1080, skipping any already bound port.the naming convention should be automatic as well, and perhaps numbered instead of named ; else just use the first and last few characters of the public key.
A note on the config
any proxy which is started is written to the config by the visor API.
If it was actually written there by the cli and the config was watched by the visor, that would be one thing, but it doesn't make a lot of sense if you want to start 100 proxies to have them all be configured in the visor's config. It's more of a configuration at runtime when starting a proxy, though the way we have it currently it's possible to manually configure autostart.
This is something we will need to figure out a better solution for going forward, but I don't have a suggestion to address that currently.
i can only state that no change to the config which is made currently persists updates, on linux. See the package documentation wiki article for details on this.
The text was updated successfully, but these errors were encountered: