[CXX-2349] Test Serverless behind a load balancer to prevent test breakage Created: 16/Aug/21  Updated: 12/Jun/23

Status: Blocked
Project: C++ Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: size-small
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Issue split

 Description   

Summary

TheĀ serverless test suite is currently run directly against Atlas proxies, as this allows drivers to run certain test against a single proxy if required (e.g. if a failpoint needs to be tripped) and target failpoints to individual proxies (e.g. for the mongos pinning tests). However, in the near future the proxies will be moving behind a load balancer, which makes both of these impossible.

The existing load balancer tests avoid this issue by spinning up two different load balancers, one that fronts a single mongos and one that fronts multiple, and conditionally uses each as necessary. We could consider doing something similar for serverless, though it would require changes Atlas side.

Motivation
Without a solution to this problem, drivers testing of serverless will be limited.

Does this ticket have a required timeline? What is it?
All serverless instances will be moving behind load balancers in ~1 month.

Is this ticket only for tests?

Yes

Notes for Language Authors

Drivers that already implemented Serverless testing before load balancing must opt in to testing load balanced Serverless instances.

  • Pass LOADBALANCED=ON as an environment variable to .evergreen/serverless/create-instance.sh to create a load balanced AWS backed instance.
  • Use the new expansions SINGLE_ATLASPROXY_LB_URI and MULTI_ATLASPROXY_LB_URI in place of SINGLE_LB_MONGOS_URI and MULTI_LB_MONGOS_URI in load balancer tests.
  • See the Go POC for an example of updating existing Serverless.

Generated at Wed Feb 07 22:05:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.