rfc20: reserve leading + for instance-local properties - #545
Conversation
|
|
Problem: Flux may add resource properties itself to describe the instance rather than the hardware, such as a property representing queue membership. There is no way to tell such a property apart from one that describes the hardware, so a job's generated R may inherit instance properties that have no meaning in a child instance. Define a leading + in a property name to mark an instance-local property: one that describes the containing instance rather than an attribute of the hardware. The literal property still applies to its execution target ranks, but because it describes the instance it MAY be omitted from a resource set generated for a job or a child instance. Assisted-by: Claude:Opus-4.8
|
|
grondo
changed the title
|
Tweaked slightly to allow properties with leading + to indication "instance local" more generally, instead of just auto-added. |
| themselves, an instance-local property MAY be omitted from a resource | ||
| set generated for a job or a child instance. |
There was a problem hiding this comment.
Would these properties be stripped from allocated R sets (e.g. what gets stored in the job KVS dir) by the scheduler? Or just stripped by the sub-instance resource module when it builds the inventory?
If the scheduler should strip these, the change currently wouldn't require a fluxion change since R is stored via libschedutil.
There was a problem hiding this comment.
I was thinking the scheduler would strip them, but intentionally left that unspecified in the spec.
There was a problem hiding this comment.
To be more clear, by "the scheduler" I did indeed mean the thing generating the resource set for a job, i.e. the R stored in the KVS would have instance-local properties stripped, since they're somewhat meaningless in that context. Whether that is done by the actual scheduler or via something after the fact (libschedutil or the Python equivalent) is probably just an implementation detail and doesn't need to be in the spec (unless you'd prefer that?)
There was a problem hiding this comment.
That seems right to me and you're right, libschedutil vs scheduler is implementation detail. I was asking whether the stripping was occuring in the enclosing instance or the sub-instance. I'm hearing enclosing instnace, which i agree with.
It's probably OK IMHO to be firm and use SHALL here as well as call out that the scheduler writes R and is responsible for this.
2 participants
Problem: There is no way to differentiate properties in a resource set that were applied automatically by Flux apart from a property configured manually, so tooling cannot know which properties describe the instance versus the resources. This leads to allocated R objects inheriting properties that may have no meaning in a subinstance.
Reserve a leading + in a property name to mark a property that Flux added automatically rather than one configured manually. The literal property still applies to its execution target ranks, but because it describes the containing instance it is intended for internal use and MAY be omitted from a resource set allocated to a job.
Assisted-by: Claude:Opus-4.8