Page MenuHomePhabricator

Support working copies and separate allocate + activate steps for resources/leases in Drydock
ClosedPublic

Authored by epriestley on Sep 18 2015, 12:37 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 7:38 AM
Unknown Object (File)
Sun, Dec 15, 4:24 PM
Unknown Object (File)
Fri, Dec 13, 1:57 PM
Unknown Object (File)
Sat, Nov 23, 1:01 PM
Unknown Object (File)
Fri, Nov 22, 4:50 PM
Unknown Object (File)
Fri, Nov 22, 1:04 AM
Unknown Object (File)
Wed, Nov 20, 2:17 PM
Unknown Object (File)
Wed, Nov 20, 2:16 PM
Subscribers
None

Details

Summary

Ref T9253. For resources and leases that need to do something which takes a lot of time or requires waiting, allow them to allocate/acquire first and then activate later.

When we allocate a resource or acquire a lease, the blueprint can either activate it immediately (if all the work can happen quickly/inline) or activate it later. If the blueprint activates it later, we queue a worker to handle activating it.

Rebuild the "working copy" blueprint to work with this model: it allocates/acquires and activates in a separate step, once it is able to acquire a host.

Test Plan

With some power of imagination, brought up a bunch of working copies with bin/drydock lease --type working-copy ...

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Support working copies and separate allocate + activate steps for resources/leases in Drydock.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added reviewers: chad, hach-que.

The one thing that this makes slightly "worse" in some sense is that bin/drydock lease previously "could"[1] complete an allocation on its own entirely in-process without the daemons running. It no longer can.

This makes debugging a little more complicated but blueprint mechanics a lot simpler. We could restore this capability eventually but I think it's a lot less important now than it was when I wrote this code (I think we didn't even require you to run the daemons when the first version of this landed).

[1] Probably rarely/never in practice.

hach-que edited edge metadata.
hach-que added inline comments.
src/applications/drydock/blueprint/DrydockWorkingCopyBlueprintImplementation.php
84–88

It would be useful in future to be able to lease against an existing host, if you're leasing multiple working copies (for different repositories).

src/applications/drydock/worker/DrydockLeaseWorker.php
42

Is there a reason to not just make this yield?

This revision is now accepted and ready to land.Sep 18 2015, 1:04 AM

The main reason I'm TODO'ing the error handling is because I think it might end up going through some layer of indirection (e.g., which sets "waiting" flags on the lease or resource, or does logging, or decides how long to yield for, or whatever else) and want to figure that out first. It will almost certainly end up either being a direct Yield or some thin wrapper around a Yield, but I'm leaning toward it probably being a wrapper that just doesn't have any specifics yet.

I'm proooobbbbablllly going to tackle logging next, which might touch this enough to provide some clarity.

chad edited edge metadata.
This revision was automatically updated to reflect the committed changes.