fix(horde): allow inbound access to horde agents on ports 7000-7010 from other horde agents

[jorisdon]

Issue number: N/A

Summary

Changes

This adds a security group rule to the Horde Agents security group that allows inbound access on ports 7000-7010 from the same security group. This enables usage of UnrealBuildAccelerator.

User experience

Prior to this change, when using UnrealBuildAccelerator, users would see only a single agent performing and completing actual work, visible as bars in UbaVisualizer that eventually turn green on that agent, whilst others remain grey. Tasks would eventually fail.

This changes fixes this, by allowing build agents to transfer files and context between each other, resulting in is builds being performed on multiple build agents successfully, and tasks not failing.

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Documentation changes not necessary for this change.

Is this a breaking change?

No

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created might not be successful.

[henrykie]

I'm good with this for now, but eventually we should add a "UBA" flag or something to enable this. Pools that are used for UBA are different than pools used for build automation.

[gabebatista]

lgtm

[jorisdon]

I'm good with this for now, but eventually we should add a "UBA" flag or something to enable this. Pools that are used for UBA are different than pools used for build automation.

Can you expand on the differences a little? I need to dig deeper into this as I think it may warrant a different approach entirely (a higher order module?)

[henrykie]

Sure.

UBA communication occurs over ports 7000-7010. UBA could use Spot. The way the "agents" variable us used in the long term may justify multiple SGs per agent group.

Lets say I want windows builders that are used for build automation. These machines need to be accessible from Horde over gRPC (already handled). These machines can scale up and scale down, but probably can't use spot. The type of backing store we use and the size of the machines is customizable, but there are definitely recommendations.

Now lets say I want linux builders that are used for UBA (either from the windows builders above, or from external users). These machines need to be accessible over 7000-7010 from any initiating machine.

[kylesomers]

Sure.

UBA communication occurs over ports 7000-7010. UBA could use Spot. The way the "agents" variable us used in the long term may justify multiple SGs per agent group.

Lets say I want windows builders that are used for build automation. These machines need to be accessible from Horde over gRPC (already handled). These machines can scale up and scale down, but probably can't use spot. The type of backing store we use and the size of the machines is customizable, but there are definitely recommendations.

Now lets say I want linux builders that are used for UBA (either from the windows builders above, or from external users). These machines need to be accessible over 7000-7010 from any initiating machine.

Agree this is something that should be configurable but we need to identify the requirements for what that should look like separately. Opened #362 to discuss this.