Feature/aliyun oss adapter

[ringtail (ringtail)]

feat: Add Alibaba Cloud OSS storage backend & fix gVisor network restore on ACK clusters

Problem

OSS Storage Backend

Agent Substrate currently only supports GCS as the snapshot storage backend, preventing deployment in Alibaba Cloud environments. OSS support is needed for multi-cloud compatibility.

gVisor Network Restore Failure

On ACK (Alibaba Container Service for Kubernetes) clusters, ResumeActor fails 100% of the time with:

while restoring eth0 in interior netns: while restoring route 1: network is unreachable

Root cause: Terway CNI uses 169.254.1.1 (link-local) as the pod gateway. This address is unreachable from gVisor's interior network namespace since it exists on the host side of the veth pair.

Solution

OSS Adapter

• Implement ObjectStorage interface for Alibaba Cloud OSS (GetObject/PutObject)
• Support oss://bucket/path URL scheme in ParseObjectURL
• Enable via environment variables: ATE_STORAGE_BACKEND=oss, OSS_ENDPOINT, OSS_ACCESS_KEY_ID, OSS_ACCESS_KEY_SECRET
• Dependency: aliyun-oss-go-sdk v3.0.2

Link-Local Route Graceful Fallback

• In restoreLink(), when netlink.RouteReplace() fails, check if the gateway is a link-local address using net.IP.IsLinkLocalUnicast()
• For link-local gateways: log a warning and continue (gVisor manages its own internal networking, pod gateway routes are unnecessary)
• For other gateways: still return the error as before

Testing

Unit Tests

• OSS client: GetObject/PutObject success and failure paths, 100% coverage
• ParseObjectURL: oss:// scheme parsing validation
• Link-local route fallback: skip on link-local + error on non-link-local + success path

Benchmark Results

Operation	Avg Latency	P95	Success Rate
SuspendActor (Checkpoint to OSS)	243ms	~330ms	100%
ResumeActor (Restore from OSS)	273ms	~330ms	100%
GetActor	<1ms	<1ms	100%

Environment: ACK cluster, OSS internal endpoint (oss-ap-northeast-1-internal.aliyuncs.com), single worker serial loop.

Acceptance Results

• OSS storage backend confirmed working: atelet logs show "Using Alibaba Cloud OSS storage backend"
• Full checkpoint/restore pipeline operational: 1168 requests with zero errors
• One complete Suspend+Resume cycle takes approximately 516ms
• Throughput: ~1.4 cycles/s per worker in serial mode

[Eitan Yarmush (EItanya)]

FYI I think #110 will make the route replace fixes in this PR unnecessary.

[Benjamin Elder (BenTheElder)]

Is there not S3 compatibility? GCS was used for the initial POC but we already support S3 API.

[ringtail (ringtail)]

FYI I think #110 will make the route replace fixes in this PR unnecessary.

Thanks for the heads-up! You're right — with the veth-pair architecture in #110, the eth0 route restore path that triggers the link-local issue no longer exists. Happy to drop that commit once #110 lands.

[ringtail (ringtail)]

Is there not S3 compatibility? GCS was used for the initial POC but we already support S3 API.

Good point! OSS does support S3-compatible API (endpoint: s3.oss-{region}.aliyuncs.com), and our use case (GetObject/PutObject for snapshots) is fully covered. The current S3 adapter just needs an endpoint override to work with OSS directly.

I'll update this PR to:

1. Add AWS_ENDPOINT_URL_S3 support to the S3 adapter
2. Remove the dedicated OSS adapter (since S3 compat covers our needs)
3. Add a configuration example for using S3 mode with Alibaba Cloud OSS