-
-
Notifications
You must be signed in to change notification settings - Fork 123
feat: [draft] Add name property to config connections for use in --connect {name} option
#162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -40,6 +40,7 @@ func main() { | |
| cli.BindEnvToFlag(cmd, "connect", "UNCLOUD_CONNECT") | ||
| cli.BindEnvToFlag(cmd, "uncloud-config", "UNCLOUD_CONFIG") | ||
|
|
||
| configPath := fs.ExpandHomeDir(opts.configPath) | ||
| var conn *config.MachineConnection | ||
| if opts.connect != "" { | ||
| if strings.HasPrefix(opts.connect, "tcp://") { | ||
|
|
@@ -55,18 +56,34 @@ func main() { | |
| conn = &config.MachineConnection{ | ||
| SSHCLI: config.SSHDestination(dest), | ||
| } | ||
| } else { | ||
| dest := opts.connect | ||
| if strings.HasPrefix(dest, "ssh://") { | ||
| dest = dest[len("ssh://"):] | ||
| } | ||
| } else if strings.HasPrefix(opts.connect, "ssh://") { | ||
| dest := opts.connect[len("ssh://"):] | ||
| conn = &config.MachineConnection{ | ||
| SSH: config.SSHDestination(dest), | ||
| } | ||
| } else { | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have mixed feeling about this change. Originally, The separation was IMO clear, but now Most commands also define the I think we shouldn't change the current behaviour of What scenarios do you have on your mind where you would want to manually specify what connection to use for a specific command? Maybe we should describe some strong use cases first to work out what the best UX is. From my personal experience so far, I had to manually switch connections only when I try to access my home cluster when I'm not at home (rarely). I described the use case here: #119 (comment). But in this case, I need to change the default once and then use it for the entire session until I'm back home. For my use case, having an interactive command for changing the default connection or a non-interactive one like If for some reason one need to run a one-off command connected to specific machine, I think specifying its SSH target should be fine. More over, @luislavena introduced a new So if one defines something like this in they can ssh to it using just I think this path of supporting Please let me know what you think @jabr @luislavena
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The inspiration to add it came up when working on the wireguard command: for that tool, you really need to be connecting directly to the machine you want to inspect, as proxying the gRPC call is likely not going to work when you actually need to use that command (i.e. the machines aren't talking properly so they can't proxy the call). So I wanted to use the
So I was just editing the However, the For what it's worth, I'd tried that Maybe it should just be logic in the wireguard command, like Anyway, I'm not hard set on anything here. Just going through my thought process on why I ended up with it like this. 😄
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another thought I had last night: The one thing in this branch that I think we're likely all agreed is useful is removing the connection entry for a machine when the machine itself is removed from the cluster. (There was a TODO note in the code about doing that.) To do that, we'll need something to connect the entry to the machine itself, but perhaps that should just be the machine ID. And then this branch (or another branch/PR might be better for a clean start) just does the add/remove bits of this but with the ID not the name (and machine rename no longer being relevant). I'm not sure the "named connection" is then even necessary with Luis's What do you think?
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I really appreciate you shared your thought process! This all totally makes a lot of sense
I'm pretty sure you're not the only one and I'd personally love to be able to make this work like that reliably. Slightly tangential to this PR, but I'm planning on creating a managed public service that would optionally allow connecting machines to to simplify access and management. In this case, the connection may look like this (no ssh): But this will only complement the current ssh options. So the problem with managing ssh connections still exists.
Agreed
Using machine ID sounds like the most "correct" (more stable) approach we considered so far. Although, not the most user-friendly imo. Note also that this won't save us from getting a stale config when there are multiple cluster users and one of them removes a machine. We can do our best effort but this still won't be a complete solution anyway unfortunately. I also don't expect that adding/removing machines is done very often so could not be a big of a problem.
I would love to make the @luislavena's work on ssh+cli the default first (assume
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that approach. It would also have "just worked" for me with my initial expectations that way, too, since I have I'd like to close this PR now, but I'd be happy to make new ones for either of these if you want to pursue them now:
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We can't make it the default until we address the issue described here #173 (comment). It would also be good to test it for some time for the practical scenarios before switching the default.
Let's do this one. This approach seems to be the most pragmatic of what we've discussed
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. PR for storing Machine ID in corresponding connection (and removing with machine): #182 Closing this one. |
||
| // If the connect string doesn't contain "@", it could be a machine name. | ||
| if !strings.Contains(opts.connect, "@") { | ||
| cfg, err := config.NewFromFile(configPath) | ||
| if err == nil { | ||
| for _, c := range cfg.Contexts[cfg.CurrentContext].Connections { | ||
| if c.Name == opts.connect { | ||
| conn = &c | ||
| break | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| // Default to assuming it is an ssh destination. | ||
| if conn == nil { | ||
| conn = &config.MachineConnection{ | ||
| SSH: config.SSHDestination(opts.connect), | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| configPath := fs.ExpandHomeDir(opts.configPath) | ||
| uncli, err := cli.New(configPath, conn) | ||
| if err != nil { | ||
| return fmt.Errorf("initialise CLI: %w", err) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned in another comment, we should use the manually specified context (
opts.context) if specified and fall back to the current one.