docs: distributed execution is invalid

[mikeshultz]

This probably beyond just the docs, but the docs are what brought me here.

In the section on Distributed Execution, it suggests running the "client" (really the runner, I guess?) as silverback run "example:app".

This would run the entire app, runner and worker. Then suggests running silverback worker. I don't think this is really what's intended.

I think we either need an idler app (similar to platform runner) or maybe a command that executes without the worker, if possible.

[linear]

SBK-551 docs: distributed execution is invalid

[fubuloubu]

That was somewhat my intent behind making the runner "stateless" (e.g. not dependent on having any particular app)

What we could do actually is make the app "optional" in silverback run e.g. if you don't add a bot there it defaults to an "idle app" for the runner to run with and collect tasks from the worker (but maybe also display something that says like "please run your app w/ silverback worker" if you use that configuration)

[mikeshultz]

That was somewhat my intent behind making the runner "stateless" (e.g. not dependent on having any particular app)

What we could do actually is make the app "optional" in silverback run e.g. if you don't add a bot there it defaults to an "idle app" for the runner to run with and collect tasks from the worker (but maybe also display something that says like "please run your app w/ silverback worker" if you use that configuration)

Still not really sure what you mean by stateless. But generally the suggested interface sounds okay. Though the default InMemoryBroker won't play nice with this behavior. And forcing a redis configuration equally sounds bogus.

So if we're going to lean into the distributed running, we should come up with something easy for local dev.

Though I'm not sure distributed use cases are ever going to be common.

[fubuloubu]

Still not really sure what you mean by stateless.

Maybe "app-less" or "app-agnostic" is a better way to say it

[fubuloubu]

Though I'm not sure distributed use cases are ever going to be common.

I agree with this, that for like 80% of users they will be happy if they have an easy way to take a local app they've developed, build it into an image, and upload that to the cluster and have it work the first time they do it. Some people are always going to have problems though, and they're gonna need a way to debug why it's not working properly both in a container (mostly this) and in the cluster environment. We can pull their images and debug ourselves locally at first, but that is definitely not going to scale well, so we should try to give users a few tools for debugging purposes.

[mikeshultz]

Some people are always going to have problems though, and they're gonna need a way to debug why it's not working properly both in a container (mostly this) and in the cluster environment. We can pull their images and debug ourselves locally at first, but that is definitely not going to scale well, so we should try to give users a few tools for debugging purposes.

This should absolutely not being the concern of the user. If their bot runs locally but does not on the platform, that's a bug in Silverback. There's no case where I would want a regular user to have to have intimate knowledge of how the platform works to debug their bot.

Though I'm not really sure this issue has anything to do with the platform. More on the Silverback CLI and how we expose the distributed configuration.

[fubuloubu]

Some people are always going to have problems though, and they're gonna need a way to debug why it's not working properly both in a container (mostly this) and in the cluster environment. We can pull their images and debug ourselves locally at first, but that is definitely not going to scale well, so we should try to give users a few tools for debugging purposes.

This should absolutely not being the concern of the user. If their bot runs locally but does not on the platform, that's a bug in Silverback. There's no case where I would want a regular user to have to have intimate knowledge of how the platform works to debug their bot.

We're saying the same thing, I'm just saying we will never get it 100% right, and we need to think of how the user is gonna quickly give us the information they need for us to debug with that doesn't require an hours long debug session in discord.

[mikeshultz]

We're saying the same thing, I'm just saying we will never get it 100% right, and we need to think of how the user is gonna quickly give us the information they need for us to debug with that doesn't require an hours long debug session in discord.

I don't think we're saying the same thing. You suggested we bring the distributed concept to the forefront. I'm saying I think that's probably confusing to users and only useful in edge cases. But you chose your favorite solution.

We just either need to fix the CLI or the docs because right now the suggested way to run distributed silverback is incorrect.

[fubuloubu]

I'm saying I think that's probably confusing to users and only useful in edge cases

We're saying the exact same thing

We don't want this to be the suggested way to do things, but there are corner cases that people will occasionally hit and we need docs and/or CLI command to run so they can get unstuck easily

---

My further point is that the way people are likely to get stuck is on how the app is containerized, or if there is a difference in how it works in a cluster environment vs. locally.

Yes of course if it works differently it is a bug, but we cannot prevent 100% all potential differences between the two because they are different environments