Page MenuHomePhabricator

Implement Chronicle v0.9
AbandonedPublic

Authored by hach-que on Jun 20 2014, 4:56 AM.

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Maniphest Tasks
T5207: Implement Chronicle
Summary

Resolves T5207. This implements Chronicle to a point where it works and you can trigger Harbormaster builds on a scheduled basis. It probably still needs some usability improvements before people can generally use it (in particular, the UI for editing the period on which the trigger fires is just a JSON blob).

It's currently hidden from the launcher and marked as beta.

Test Plan

Tested everything and it worked.

Event Timeline

hach-que retitled this revision from to Implement Chronicle v0.9.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)
hach-que added a reviewer: epriestley.
epriestley edited edge metadata.

D11419 implements an alternative piece of drive infrastructure which is better suited for other applications we want to pursue. It's a bit more low-level than this.

A couple of notes about differences in design inline. It doesn't have any UI and probably only overlaps with about 20% of this diff (basically, the daemon part).

I don't have any plans to upstream this anytime soon, just kicking it back to you since there's at least some relevant upstream progress now and I looked through it in writing D11419.

src/applications/chronicle/action/ChronicleAction.php
3

Major difference here is that trigger actions do as little work as possible (they are strongly encouraged to queue a worker task instead of executing any logic), to make it as hard as possible to ever overload the daemon. This could use that model by having a thin trigger action which queues a task to execute a Chronicle action, though.

src/applications/chronicle/daemon/ChronicleDaemon.php
38–57

This is the biggest difference in the two designs: this approach has a huge race window, up to 65 seconds + time it takes to execute the trigger, which may be long.

If a user modifies the trigger during these 65+ seconds from the web UI, their changes will be lost after the trigger executes and calls save(), overwriting the trigger and reverting it to a state it was in 65 seconds ago.

There's also a small race window at the end where a user can load, the daemon saves, then the user saves. In this case, the event will execute twice. That's OK for builds, but not good for email notifications and catastrophically bad for billing.

D11419 has more complicated infrastructure, but I believe it prevents the daemon from ever racing against the application.

This revision now requires changes to proceed.Jan 16 2015, 1:03 AM

We'll pursue using D11419 instead.