Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need mechanism to register new validator and feasibility checks with job-ingest #2049

Closed
grondo opened this issue Feb 27, 2019 · 0 comments
Closed

Comments

@grondo
Copy link
Contributor

grondo commented Feb 27, 2019

We need to define a method for a loaded scheduler or other instance component to register a new validator (or validators) and/or feasibility checks with the job-ingest module, so that jobspec not supported by the current instance can be rejected with a meaningful message at ingest.

One current proposal is to have a "configuration object" in the kvs, on which the job-ingest modules could place a watch and get updates to configuration. One issue with this is how to support the possibility of multiple updates to configuration causing a race. Perhaps the ingest module (or some other agent) could support a service (on rank 0 only?) to ensure a single update at a time, with a simple add and remove interface. (In fact, if done via a separate module, maybe this could be the start of a more generic dynamic configuration api for instances?)

Beyond the configuration, we have to determine what sorts of validators are supported by the ingest module. For the near term, it may be enough to simply swap out the json schema validator for a different schema, longer term, the following features would be nice

  • support addition of scripts/executables that can perform validation in parallel (all checks must pass) using the current workcrew
  • registration of a messaging endpoint that is interested in validating jobs (e.g. scheduler or an agent of the scheduler could perform a feasibility check on the jobspec)
grondo added a commit to grondo/flux-core that referenced this issue Feb 24, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Feb 24, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Feb 24, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Mar 1, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Mar 1, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Mar 2, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
grondo added a commit to grondo/flux-core that referenced this issue Mar 2, 2021
Problem: There is no way to reject jobs at ingest which are not
feasible.  Instead, they are queued and later have a job exception
raised when the scheduler considers them for an allocation.

Add a flux.job.validator plugin that uses the sched.feasibility RPC
to ensure job feasibility (or anything else the scheduler might want
to check) at ingest. This allows the job to be rejected before being
ingested, improving usability.

Fixes flux-framework#269
Fixes flux-framework#2049
@mergify mergify bot closed this as completed in 67a07b3 Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant