alexhsamuel / apsis Goto Github PK

It should confirm that all schedule args match job params.

Experiment with this... does it look good?
e.g. very pale red for error state

Add a mechanism to archive runs so they aren't visible anymore.

and shut down cleanly.

Handle exceptions carefully when:

• performing any template expansion
• binding arguments
• calling programs, actions, or any other user-extensible types

Produce useful diagnostics and put the run into the error state.

If the apsis program receives an error response from the REST service, it should show the error message.

When invoking ssh:

BatchMode: yes
CheckHostIP: no
StrictHostKeyChecking: no

also disable X11 forwarding and whatever else we don't need.

On a run view, show:

• the original rerun
• all reruns in the set
• the latest rerun

Hide the rerun button unless this is a the latest rerun.

The "load ## bytes" link is always displayed.
Automatically load up to N bytes... 1 MB?

If a ScheduleAction is about to schedule an existing run, it should rerun instead?

In jobs, order the arguments in the same order they're specified in the job.

Don't query since the beginning of time.

(This repo was originally derived from github.com/alexhsamuel/ora.)

Include a link as

• raw URL
• HTML link with description
• GH-style markdown

Provide mechanisms for scheduling a daily run other than at a daytime on that date. Possibilities:

• date offset
• calendar date offset
• negative daytimes / daytimes > 24:00
• arbitrary ora expressions

When a run output is large, its output isn't loaded automatically. The link to load it is broken.

Uncaught TypeError: Cannot read property 'output_url' of undefined

from RunView.vue:120

When watching a run, the history does not live-update.
Add this to the run websocket? or poll?

This is partly because log history is immediately added after run transitions.

Put it in the store, so that when we come back to the view the search/filter state is still there.

When the run socket disconnects and is reconnected, we need to flush the internal runs list.

To make it easier to learn what they mean.

If ssh for starting the agent fails slowly, this blocked Scheduled. Add a timeout.

Specify a loader with yaml.load().

Provide a mechanism to configure short names for programs, schedules, and actions in the config file.

That way browsers' link shortcuts (middle-click etc.) will work.

So that we don't block the event loop in a huge JSON marshaling.

Percent busy? Latency for "now" tasks? Queue length?

Paragraphs get mushed together.

This column always contains the same value.

Possibly, use the additional horizontal space to expand params into individual columns.

With "since:1d", jobs that started running more than a day ago aren't shown. Running jobs should be shown regardless of the time range. Possibly blocked jobs too.

Otherwise there are duplicates.

The scheduler should start all ready runs concurrently, rather than awaiting each one to start.

If two jobs are started simultaneously on the same host as the same user, a race can cause multiple agent processes to start. Only the last one is live, as it overwrites the pid file.

Improve atomicity in apsis.agent.main.

We want to to support hierarchical job names, e.g. folder / job.
Currently jobs.load_yaml_files() reads subdirectories recursively and creates job ids containing /.
This breaks the REST API as the job id goes into URL paths and / is not allowed.

• Do we want to separate job id from job name now?
• For job names, how do we specify paths? Using /?
• How does this get mapped to URLs?
• How is this displayed in the web UI?

Otherwise, we may emit a log message after the event loop has shut down, which will fail when it tries to add a record to an asyncio.Queue.

This blocks until the run becomes success, failure, or error.

For expected runs, we should populate the program (i.e. bind the job program) so that API requests show it. However, don't persist the program. Likewise for precos.

• Bind program, precos when run is created.
• Don't persist program, precos for expected runs in run DB.
• When recreating expected runs, re-bind them.

It should probably navigate somewhere, like the page for the rerun.

This should not be shown for jobs that haven't been started.

In apsis log, show agent process number and other stuff.
In agent log, show agent process number on POST.
In command line agent, show proc and port of connected agent.
Better debugging of agents going up and down, to figure out why they are left behind.

apsis/service/api.py:416 still uses until.

Some expected runs produce entries in run_history but their run_ids are reused for other runs if Apsis is restarted. That causes the run_history for a run_id to mix history from multiple runs.

Either store the largest run_id in the DB, or make "expected" runs real and store them in the database. Or both.

For example,

# Every hour, 10 min past the hour.
schedule:
    type: interval
    interval: 3600
    offset: 600

It seems to show the Apsis hostname, not the name of the host on which the run was run.