be22bc735a
As part of the fix for #10668, the logic was adjusted so that the default (highest-priority) network is used in the `ContainerCreate`, and then the remaining networks are connected via calls to `NetworkConnect` before starting the container. Unfortunately, `ServiceConfig::NetworksByPriority` is neither deterministic nor stable when networks have the same priority. It's non-deterministic because the order of networks from parsing YAML is random, since they are loaded into a Go map (which have random iteration order). Additionally, it's not using a `SortStable` in `compose-go`, so even if the load order was predictable, it still might produce different results. While I look at improving `compose-go` here to prevent this from tripping us up in the future, this fix looks at _all_ networks for a service and ignores the "default" one now. Before, it would always skip the first one in the slice since that _should_ have been the "default". Signed-off-by: Milas Bowman <milas.bowman@docker.com> |
||
|---|---|---|
| .. | ||
| api | ||
| compose | ||
| e2e | ||
| mocks | ||
| progress | ||
| prompt | ||
| utils | ||
| watch | ||