Implement wait flag for ctl commands

[brooksmtownsend]

Imperatively interacting with a wasmcloud host, or a lattice of interconnected hosts, it's important to be able to know when certain events take place. For example, when you issue this command to a wasmcloud host:

wash ctl start actor wasmcloud.azurecr.io/subscriber:0.2.0

You receive an acknowledgment that the actor start event has been received. All this means is that your command was successfully delivered to the host and that the host is going to proceed with pulling the actor from our OCI registry and starting it. What you don't get from this acknowledgment is the assurance that the actor actually was started.

I propose a --wait flag that can be appended to the start, stop, link and update subcommands under ctl. These are all commands that return with an acknowledgment but not a confirmation of the command executing. When the --wait flag is supplied, the command will instead block until the appropriate event can be observed (e.g. ActorStarted for start actor).

In order to monitor the event stream, there are two possibilities:

• When connected to hosts running in a lattice via NATS, events are published as NATS messages that can be monitored. This can be used to monitor events when connected via NATS.
• When connected to a host without NATS (which will be a possibility in the REPL after Fully contained REPL host (e.g. no NATS) #92 ) the host can be built with an event sender that can be monitored for the same events that would be sent across NATS.

Both of these possibilities are important. When using wash as a command-line interface, we'll want to monitor events that are flowing over NATS messages, as the control interface operates on a lattice that's connected to via NATS. We'll want to do the same thing when wash up is launched with a NATS connection. When the REPL is launched without a NATS connection (after #92 ) we should directly build a host with an event receiver that can be used to monitor these events.

[mattwilkinsonn]

Would it be better to flip the flag around? Have the default behavior be waiting for the actor to start, and someone can pass --no-wait to skip that?

[brooksmtownsend]

I think it depends on the use case. For actors it's not really a big deal, but for capability providers especially on constrained networks it can take time to download the 20MB+ file and so waiting around would be bad if using wash to script commands.

Overall the idea is that adding a --wait flag is a compatible feature with what we have today as it doesn't change the default behavior, but adding a --no-wait makes it so that starting actors and providers has a different behavior. I could be convinced to change, but in my mind it makes sense for wash to know that the command got accepted and allow users to proceed with other actions by default, and in the use case where you really want to know that resources start then you can --wait

[mattwilkinsonn]

I'm just thinking about other tools that do similar things, like docker compose up. Even with the -d detached flag it still blocks until the containers are created and running, which would be equivalent to 'waiting' in our context. And from an average user's perspective the command waiting by default seems to make more sense to me, as they want to run the command and know that the thing they just ran is now working. Whereas scripting is a more advanced use case, so they should be okay with passing an extra flag to skip the wait time, at least IMO.

I'm open to either though. I just think default waiting would be more in line with what an average user would expect.

[brooksmtownsend]

@mattwilkinsonn that's a fair point. With proper documentation, I think that we'll be able to change the behavior and provide a better experience overall 😄 . So to confirm, we'll go with wash ctl start actor blah which will subscribe for the actor_started event (and actor_start_failed), and wash ctl start actor blah --skip-wait which will skip waiting for the actual started event.

[mattwilkinsonn]

Should this be handled inside the control interface's client? We could add a method on it that subscribes to wasmbus.evt and looks for the com.wasmcloud.lattice.actor_started message?

Alternatively we could handle it inside wash by making our own connection to NATS, but i'm not sure making two separate connections makes sense.

[brooksmtownsend]

Should this be handled inside the control interface's client? We could add a method on it that subscribes to wasmbus.evt and looks for the com.wasmcloud.lattice.actor_started message?

Alternatively we could handle it inside wash by making our own connection to NATS, but i'm not sure making two separate connections makes sense.

We have something ready for this! https://docs.rs/wasmcloud-control-interface/0.13.0/wasmcloud_control_interface/struct.Client.html#method.events_receiver. What wash could do is instantiate an events receiver before sending the operation and try to receive events for a specified longer timeout. This way you can finish the command when you receive the appropriate command.

This will also reuse the same NATS connection, so no duplication.