Dong H. Ahn
Dong H. Ahn
This was recently hit by @grondo as well. I believe an error in hwloc reader in handling a malformed (?) storage object within hwloc in dealing with certain storage types.
https://github.com/flux-framework/flux-sched/pull/909. But it would be best to fix at the hwloc reader level. Keeping it open.
What does `flux-core` do in this case? If it handles this sufficiently well, we should use the same trick. Otherwise, this should be fixed at both places..
I guess this is still an issue. Wouldn't it be better to be handled by `sharness.d/flux-sharness.sh` so that this can be solved for both flux-core and fluxion?
@SteVwonder can chime in. I have no clue sorry.
The code that does this automatic reduction is: https://github.com/flux-framework/flux-sched/blob/master/src/cmd/flux-tree#L609 https://github.com/flux-framework/flux-sched/blob/master/src/cmd/flux-tree#L619 I supposed one can add some warning prints to both sites. Seeing this message from the top level instance is...
From PR #649: > As we discussed before, I'm not entirely happy with the current way of configuring queues. But I thought there is a benefit of getting the runtime...
> Config file looks nice to me. In case you might want future sub-tables below qmanager, it may be wise to add queue configurations to their own table queue? So...
> Generally, it would be nice if the core-provided flux_conf_t interface could help out with precedence and parsing load-time options. Using the config file above as an example, it would...
> However, I agree with @garlick, that likely setting complex configurations on the commandline isn't an initial (or important, or perhaps even useful?) use case for now, so maybe some...