feature: range request in resource-query (or more general underlying fluxion)

[vsoch]

We would like to have the ability to specify ranges. E.g., right now for my ice cream shop, to create different sizes I have to explicitly define them:

<!-- A small has one scoop -->
<edge id="small-cup" source="cup" target="scoop"></edge>

<!-- A medium has two scoops -->
<edge id="medium-cup" source="cup" target="scoop"></edge>

<!-- A large has three scoops -->
<edge id="large-cup" source="cup" target="scoop"></edge>

Ideally, I could just say that the customer is allowed to get 1-3 scoops.

<!-- A cup can have one, two, or three integer scoops -->
<edge id="cup" source="cup" target="scoop">
    <data key="min">1</data>
    <data key="max">3</data>
</edge>

In more real world use cases, if we are doing some kind of compatibility check we will likely be looking for mins/maxes (and not necessarily a range, but could be). I'm not sure where this translates into flux-sched logic - @grondo we talked about this today, and thought you might be the one to ask! i looked in flux-core and searched for "range" in the issues but didn't find anything that looked like a match.

Pinging @zekemorton @milroy to add more intelligent discussion to this issue than I can offer. 😆

[grondo]

Canonical jobspec supports this concept as described in the RFC 14 Resources section (see the description of the count: min, max, operator and operand keys).

However, Jobspec V1 requires count be a single integer value (See RFC 25), so there is no support for min, max, etc in current flux-core.

I don't know about resource-query since it is a fluxion specific tool and thus doesn't apply to the rest of the flux framework projects. I imagine there is a way to specify the min/max for count, though. @trws might know.

[vsoch]

Thanks @grondo!

I don't know about resource-query since it is a fluxion specific tool and thus doesn't apply to the rest of the flux framework projects.

We don't need it specifically for resource-query, but generally using the flux bindings. We chat about it today, and are wanting to just build a basic tool (that doesn't start from resource-query) that uses the fluxion bindings (is that the right way to put it?) to (high level):

1. instantiate Fluxion
2. Create the context, pass in the graphml for some domain (specify instead of JGF we are using graphml)
3. The defaults should work out of the box
4. Pass in a jobspec (that matches the domain of the graphml)
5. Perform a satisfiability check rather than a match "can we represent this or not" (yes/no)

And the result should be true/false, etc. In the compatibility use case (software, kernel features, matching noodles to doodles) the library will likely be going through a list of items, sorted by preference, and checking them until there is a match (and passing on that it is chosen to some calling tool or user).

However, Jobspec V1 requires count be a single integer value (See RFC 25), so there is no support for min, max, etc in current flux-core.

So it sounds like we'd need to pass on the new ability for min/max to also be supported (some Jobspec V2)?

[grondo]

I think Fluxion does support some portion of canonical Jobspec beyond V1. I'd check in the testsuite for hints, e.g. t/t3009-resource-minmax.t and t/t3031-resource-minmax2.t look promising.

[grondo]

There's an example jobspec using min/max referenced by those tests here

flux-sched/t/data/resource/jobspecs/min_max/test002.yaml

Lines 1 to 18 in fe872c8

	version: 9999
	resources:
	- type: node
	count: 1
	with:
	- type: slot
	label: default
	count:
	min: 1
	max: 2
	operator: "*"
	operand: 2
	with:
	- type: socket
	count: 1
	with:
	- type: core
	count: 18

[grondo]

Perform a satisfiability check rather than a match "can we represent this or not" (yes/no)

Flux schedulers may offer a sched.feasibility RPC for doing a "satisfiability" check. Fluxion supports this so you could just send your jobspec to this service if Fluxion is running as a scheduler in a Flux instance, or you can figure out how to call the same functionality by looking at its implementation in the code.