I'm going to close this out since I think everything here is now reasonably represented elsewhere:

Resources still do not have expiration behaviors.

These things are now complete:

This is functional locally and headed for production after T7399 resolves enough to let us do build tier deployments without leaking live key material.

(We also need solution A in some form for our use of Drydock, so if upstream doesn't have that, we'll end up patching an implementation of solution A on top of the new API anyway)

fyi solution (A) is implemented in the revisions I wrote that add custom attributes for blueprints. I'm guessing these will be reasonably straightforward to translate to the new API, since it's mostly just updating the filtering checks (lease attributes matching resource attributes and lease attributes matching blueprint attributes).

D14144 is tangential here but gives resources and leases a meaningful destruction phase.

I think everything is setting ownerPHID now.

So my question is, how would you like us to communicate the issues we encounter, if at all, specifically concerning Drydock/Harbormaster from now on and in the future?

I apologise for filing issues on it, I know it is against the policy. I've been following Drydock/Harbormaster quite closely and we have been using it for builds for quite a while. Most of the integration you get into Phabricator has been invaluable for us in general. However, the first two outlined issues literally broke all builds for us, and while I understand that you need the agility to be able to break prototype applications, I would hope it is also valuable for you to know how the users who dare to use unsupported applications deal with the changes you make and the problems they encounter, it seems Drydock/Harbormaster in particular is moving towards a more stable place now and the implementations you've landed in with the latest changes look really solid.

Drydock is a prototype, see:

Drydock is a prototype, see:

More broadly, we're now much of the way toward a functional v1 here but most of the interesting action has been attached to T9253 rather than directly to this task, and getting this operating in the upstream has depended on Phacility changes in T7399 (I don't want any live Phacility credentials to exist on the build hosts in any form, but do want to deploy them using common cluster tooling).

General plans here:

fyi libvirt takes just a little over a minute to spin up a Linux build machine using copy-on-write disks (this includes waiting for SSH to come up and connect)

Anyway it is not for now !!

In T9431#137264, @epriestley wrote:

Some day you'll be able to spin up a container or host per build and tear it down afterward, but doing so creates a performance/efficiency tradeoff because you have to build and tear down more state per build. I suspect this tradeoff is undesirable for this project even if the code existed to make it (because host startup / teardown would likely overwhelm build cost).

This tier now exists and rCORE knows how to deploy hosts inside it.

Some day you'll be able to spin up a container or host per build and tear it down afterward, but doing so creates a performance/efficiency tradeoff because you have to build and tear down more state per build. I suspect this tradeoff is undesirable for this project even if the code existed to make it (because host startup / teardown would likely overwhelm build cost).

Although builds will be isolated from services, they won't be isolated from one another. That is, anyone who can run a build can interfere with anything else happening on the same machine.

D14117 discusses a vaguely related case where a blueprint might intentionally deny lease acquisition on a resource that it needs to process further. This pattern seems fine conceptually if/when we find real resources in the wild which fit into it.

This block has been removed in D14114 and we no longer distinguish between "lost an allocation race" and "all resources are currently full". The logic goes:

This is likely something we can improve, but I think it probably just follows T6139/T9123. I'm just going to close this until those get built and we can re-examine it if it's still problematic.

I think there are two components to this:

I expect the general shape of the code to survive, but a lot of the particulars to churn. There are lot of issues with state handling, error handling, locks, which things are responsible for what, etc., right now.

DrydockBlueprintImplementation::newResourceTemplate can't possibly work because it calls a nonexistent mutator on DrydockResource. By extension, the entire DrydockWorkingCopyBlueprintImplementation is currently unusable.

Whoops, fixed. Thanks.

Should be DrydockBlueprintImplementation::executeAcquireLease

Just jotting these down here to make sure they don't get lost: