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
Now that we separate `ray.init` from `fed.init`, there's no way to reach the cluster-level information, since each `fed.init` starts and only starts a job session.
Unless there's a global actor (or service job) that can break the job isolation and filter each job's tasks' invalid param type.
If we don't have the cluster config, why we not just use `config`? The question that we should answer before it getting finalized is whether we need the cluster config in the future at high level.
Firstly, the fact is that user can't configure the Ray cluster in a rayfed job, since the initialization of Ray cluster has separated from RayFed, i.e. fed.init.
I think the original semantic of "cluster_config" is "configure the cluster used in this job", in which case, it's a job-level config but containing all the non-business configurations.
I think the original semantic of "cluster_config" is "configure the cluster used in this job", in which case, it's a job-level config but containing all the non-business configurations.
It sounds reasonable. Let's use the config key word as the job level configurations parameter name.
Unless there's a global actor (or service job) that can break the job isolation and filter each job's tasks' invalid param type.
Originally posted by @NKcqx in #140 (comment)
The text was updated successfully, but these errors were encountered: