Support multiple farms with the same twin

[scottyeager]

Some farmers need to manage multiple farms, and in some cases, they have more than one farm that belongs to the same twin. While there's a limit inherent in the fact that each twin can only have one associated rmb-peer running at a time, I don't see any reason why multiple farmerbot couldn't run in the same docker compose deployment, sharing the other containers.

The only complication is potential key collisions in redis. For RMB messages, each reply gets a unique identifier, so there is no problem. A couple queues have non unique names though:

• jobs.db
• jobs.processor.active

These are generated upstream in baobab, so I think this can be accomplished something like this:

1. Establish a way in baobab to accept an identifier that can be added to the queue names
2. Provide an optional mechanism to give a farmerbot a unique identifier, such as a command line arg, a config field, or automatically using existing data like the farm id
3. Pass the identifier to baobab so it generates, for example, farmerbot1.jobs.db, farmerbot2.jobs.db, etc

Then the farmer can add additional farmerbot blocks to their docker-compose.yaml to manage additional farms under the same twin. Each would have it's own config directory and config file.

[brandonpille]

Although that technically can work it's not how the farmerbot was designed to do. It's a bot managing a farm. I don't think it should be able to manage multiple farms.

I also wonder how and why a user would create two different farms with the same twin....

[scottyeager]

Any time a farmer has nodes in different LANs or subnets, they need multiple farms and multiple farmerbots. There are two primary reasons for this:

• They operate nodes in different locations
• Larger farms seem to benefit from segmenting into multiple VLANs for network performance reasons (solves issues with Zos not booting properly)

The dashboard supports creating multiple farms under the same twin, and before the farmerbot there was never a reason not to do this. GreenEdge, for example, segments their nodes into different farms owned by the same twin.

The idea here is to reduce overhead for farmers who need to manage multiple farms. For a farmer with ten farms, they need to keep ten seed phrases safe and manage ten separate docker compose deployments.

In my mind, it's just about letting multiple bots coexist and share resources when possible. This can save farmers a lot of hassle (including traveling to a different location to set their nodes to boot with a different farm id), so I think it's worth implementing unless there's a good reason not to.

[brandonpille]

I'll just elaborate on the reasons you mentioned:

• It makes sense to split them up into farms if they are located into different locations for sure! But a farm is a unique thing so in my opinion it should get a unique twin too. If you take the time to create multiple farms then keeping the mnemonics should not be that big a hassle. Plus it is much safer too. And one final thing is that nodes that are in different locations won't be on the same LAN so the farmerbot will not work.
• I heard about the second one. Although doing that makes sense on the short term we can't keep going around that problem. We should fix the issue of ZOS not booting up. We can't have farms with unlimited nodes so splitting them up int multiple farms for that reason makes sense. But they are still different farms so they should get different twin ids in my opinion.

The farmerbot was designed to manage one farm, not multiple. But I'll mention it in our scrum call today.

[brandonpille]

Unless it is really needed I don't think it makes sense to implement this. The farmerbot is designed to be ran for one farm and a farm should have a unique twin id.

[scottyeager]

I won't push this because it's a fairly niche use case and is more controversial than I expected.

Since I forgot to respond earlier though, I will add my replies to these points:

But a farm is a unique thing so in my opinion it should get a unique twin too.

This has never been the case in the architecture of the Grid up to this point. Multiple farms per twin is supported everywhere except farmerbot.

If you take the time to create multiple farms then keeping the mnemonics should not be that big a hassle. Plus it is much safer too.

Creating a farm under an existing twin is about two clicks. Working with multiple twins in the dashboard is a hassle. It involves a lot more switching contexts and waiting for things to load.

About security, I disagree. Requiring the farmer to manage multiple seed phrases makes it more likely that they will use an electronic means to store them, as a convenience, and thus increase the risk that any or all are compromised. For farmers who instead handle all the seeds in the same way, the risk is the same.

The farmerbot is designed to be ran for one farm

I'm not proposing to change that. What I'm suggesting is to allow multiple instances of the bot to run within the same supporting infrastructure (twin and RMB connection).