[RFC] Default `wash ctx` behavior

[brooksmtownsend]

Background

wash ctx aka wash contexts is one of the more niche features of wash, very similar to a kubeconfig file, NATS context, or your CLI of choice's way to set a list of defaults to use when running its commands.

wash uses the context feature primarily for the wash ctl and wash call commands, in order to provide the proper connection information for control interface commands or to provide the correct cluster seed to sign an invocation, respectively.

The host_config context

Whenever you run a ctl or call command, wash automatically checks for the existence of ~/.wash/host_config.json, which is written when you start any wasmCloud OTP host on your system. This host_config is primarily intended to be used to configure hosts and includes things like NATS connection URLs, ports, credential file locations, etc. wash then uses that file to create the host_config context, meaning whenever you launch a wasmCloud host on your system wash is already configured to communicate with that host even if it's not using the default connection values.

The problem

The host_config context feature is largely unknown for the majority of users and can lead to nondeterministic and confusing behavior for developers that launch hosts with different connection values. Where a new user may expect wash to always run control interface commands on NATS port 4222, we may be reading a host_config file that says to issue requests on 4223, leading to confusing failures to connect.

Proposed solution

I propose that we keep the host_config context feature but not set it as the default context unless the user explicitly types wash ctx default host_config. Essentially this means that wash will always use the command line (clap defined) defaults for its commands until a developer specifically interacts with the ctx subcommand. Then, the developer will have a choice of using the host_config context, creating their own, or leaving the command alone.

Looking for feedback on the proposed solution.

Alternatives

We could get rid of the host_config context entirely, though I find it to be a useful way to keep wash automatically connected with hosts even if I change what NATS port I'm listening on. It's especially useful for wash call so users don't need to find the an allowed cluster seed.

Unintuitive changes that will need to happen

• wash ctx needs a way to "unselect" a default context so it can instead use command line defaults
• Our documentation needs a read-through to ensure we don't depend on this feature (I know we do for the first wash call that we ask users to perform)
• We should have documentation that's linked to in the CLI for the host_config context feature, along with info level logs in text mode indicating that we're using a specific context.

[connorsmith256]

Love this. One question:

wash ctx needs a way to "unselect" a default context so it can instead use command line defaults

What would this look like? Adding a none to the wash ctx default command, which would reset wash back to its initial state?

[brooksmtownsend]

What would this look like? Adding a none to the wash ctx default command, which would reset wash back to its initial state?

My initial thought was something like wash ctx default reset or just wash ctx default resets, but I didn't put a ton of thought into that and it feels clunky writing it out. Open to any and all suggestions

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!