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
Summary:
Pull Request resolved: #1389
All `Alloc` implementations now get their transport type from the new transport field on `AllocSpec`. When `PyAllocSpec` is converted to `AllocSpec`, it will use whatever the current default transport is, provided via the new `hyperactor_mesh::proc_mesh::default_transport` function, which reads the config var `HYPERACTOR_MESH_DEFAULT_TRANSPORT` (renamed from `HYPERACTOR_MESH_ROOT_CLIENT_TRANSPORT`). That way, if a user creates a `PyAllocSpec`, then reconfigures the default transport, then passes the old `PyAllocSpec` to an allocator, they won't get an unexpected result.
`RemoteProcessAllocator` and `MastAllocator` have slightly special handling for now so that we don't break existing v0 examples/notebooks/workflows:
- `MastAllocator` can be initialized with a transport override for testing purposes, which overrides the transport value from the `AllocSpec` passed to it.
- We eventually want `PyMastAllocatorBase` to throw an exception if the default transport isn't metaTLS, but if we did that now a bunch of v0 examples would break unnecessarily. So instead, for now, if the default transport is wrong, the user is warned and the transport is updated on the `AllocSpec` for them.
- Similarly for `RemoteAllocator`, we eventually want to throw an exception if the transport on the addresses returned by the initializer isn't equal to the default transport. But to prevent existing v0 examples from breaking, we now simply warn the user and update the transport on the `AllocSpec` to the expected value.
ghstack-source-id: 314103746
Reviewed By: mariusae
Differential Revision: D83628852
fbshipit-source-id: 6f3bb683c22677d17250698804716ae36f8997a1
0 commit comments