Skip to content

[Feature] GCP backend: allow specifying the subnetwork (currently always picks the first usable subnet in the VPC) #4254

Description

@jagretti

Problem

The GCP backend lets you pin the VPC via vpc_name, but not the subnet. Subnet selection is:

# src/dstack/_internal/core/backends/gcp/resources.py
def get_vpc_subnet_or_error(...):
    vpc_subnets = get_vpc_subnets(vpc_name, region, usable_subnets)
    if vpc_subnets:
        return vpc_subnets[0]   # <- first usable subnet, no way to influence

i.e. the first subnet returned by ListUsableSubnetworks for that VPC+region wins.

In a VPC with multiple subnets in the same region, subnets often serve different purposes (different sizes, routing, peering/VPN reachability, reserved ranges), and you may want dstack to provision instances and gateways in one subnet rather than another. Today there is no way to influence the choice — which subnet dstack lands in is effectively arbitrary. This is especially limiting for private gateways and fleets with public_ip: false, where clients can only reach the VMs if they land in a subnet the client network routes to.

Proposal

Add an optional subnetwork field to the GCP backend config (alongside vpc_name), e.g.:

- type: gcp
  project_id: my-project
  vpc_name: my-vpc
  subnetwork: my-subnet   # optional; per-region map also fine
  creds:
    type: default

When set, get_vpc_subnet_or_error would select that subnet (erroring if it doesn't exist in the region) instead of vpc_subnets[0]. Happy to contribute a PR if the approach sounds right.

dstack version: 0.21.3 (server, GCP backend; behavior unchanged on master)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions