You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should fix this. Low priority, but in the mean time, adding the issue in case anyone else stumbles across this and needs a fix to could not find AZ z2 (in network AZS [z1 z2 z3]
The text was updated successfully, but these errors were encountered:
Previously only `az` was supported. Now when specifying
multiple AZs in a subnet, all IPs from that subnet can be
used in any instance_group/job that is in a zone that the
subnet mentioned.
This can lead to interesting scenarios when using mixes of
multi-az subnets and single-az subnets, where different offsets
can mean the same IP in a different zone, or the same index could
mean different IPs in different zones. Try not to do this, as it will
likely lead to confusion down the road. However, care is made to ensure
that IPs are never re-used, regardless of what subnets/azs they were
allowed to be used by.
This should not affect any existing IP allocations, since previously the
`azs` field wasn't looked at, and the old behaviors remain the same
for `az` and no-azs.
is valid, but the operator currently only allows:
We should fix this. Low priority, but in the mean time, adding the issue in case anyone else stumbles across this and needs a fix to
could not find AZ z2 (in network AZS [z1 z2 z3]
The text was updated successfully, but these errors were encountered: