Merge pull request flux-framework#425 from grondo/issue#384

rfc27: document job feasibility service

conf.py

@@ -66,6 +66,7 @@
 linkcheck_ignore = [
     "https://help.github.com/en/pull-requests", # 403 Forbidden
     r"https://blog\.twitter\.com/.*", # 403 Forbidden
+    r"https://github.com/pmodels/mpich/commit/.*", # 406 client not acceptable
 ]
 
 

spec_27.rst

@@ -26,6 +26,7 @@ Language
 Related Standards
 *****************
 
+- :doc:`spec_3`
 - :doc:`spec_14`
 - :doc:`spec_16`
 - :doc:`spec_20`
@@ -99,6 +100,8 @@ Design Criteria
 
 - Allow the expiration time of a resource allocation to be adjusted.
 
+- Detect unsatisfiable job requests at submission time.
+
 Implementation
 **************
 
@@ -644,3 +647,27 @@ a ``sched.free`` request.
 
 If the scheduler is monitoring job exceptions, it SHOULD NOT react in ways
 that might conflict with the job manager's actions.
+
+Feasibility
+===========
+
+A scheduler or other entity MAY register a generic ``feasibility`` service
+name through which unsatisfiable jobs may be detected at job submission.
+
+The ``feasibility`` service MAY be registered on one or more nodes to
+distribute the load of feasibility checks. The job ingest validator (the
+main user of the ``feasibility`` service) runs on all ranks and issues the
+``feasibility.check`` RPC with ``FLUX_NODEID_ANY``. The request is routed to
+a local ``feasibility`` service if available, or an upstream one per RFC 3.
+
+To determine the feasibility of a job request, a ``feasibility.check``
+request is sent with the following REQUIRED key:
+
+jobspec
+   (object) The jobspec for which feasibility should be checked.
+
+If the included jobspec could not ever be satisfied, even if all resources
+were available and ready, then the ``feasibility.check`` service SHALL
+respond with a error response including a human readable error string.
+
+The response SHALL consist of an empty payload on success.

spell.en.pws

@@ -491,3 +491,4 @@ bitmasks
 DoS
 lookups
 chu
+unsatisfiable