Is there some scenario which can trigger both bindings in a host group to be brought online?

A short comment now. Thank you for the very detailed reply.

Without actually reproducing this or looking at the code, I believe this isn't a bug. You're expecting Drydock to choose particular allocation strategies:

Reproduced on

(I preemptively set the project back to Needs Information since the followup didn't involve reproduction of the issue on a valid install)

Upstream doesn't support Phabricator installed via third-party images (including Bitnami). You need to reproduce the issue on either a blank Phacility test instance, or by following the Installation Guide and reproducing it there providing it's not an environment issue.

OK -- I made a new ec2 instance with the phabricator marketplace image to make the install easier. Updated to the latest stable and could still reproduce this. I don't know why the commit branches are saying that it is branched because I git reset --hard origin/stable on all the branches. I repeat -- this is a 100% fresh machine with the latest stable channel fetched from the phacility repos.

Presuming this is resolved since it hasn't been updated in about a month, but let us know if it's still an issue after the update.

That change doesn't specifically do anything about mail tasks, but assuming they were coming out of repository imports it should probably clear them up too. I'd expect queue behavior to generally be more reasonable around repository imports once you pick up those changes.

Nope we don't have that integrated in yet (just missed our last cutoff). Once we get that pulled in I'll confirm it clears up the issue.

Did you experience these issues after D16585? My expectation is that it should be almost impossible for PhabricatorRepositoryCommitHeraldWorker tasks to stall the queue for other priority-2000 tasks after that change.

Well, just Conduit for editing -- querying is already in D16592.

I think making authorizations transactional isn't too much work. They already have PHIDs, and aren't edited in very many places.

I'm comfortable bringing this stuff upstream today:

Evan, do you think there is a route forward with this that would be feasible for me to implement upstream?

(not building locally anymore, eg, any time I want to do anything with a built binary at all, i'm actually doing it with a binary on a remote server because I can get the build results faster)

Well one facet of this is that remote servers tend to be significantly more powerful than developer machines, and so since I've implemented this downstream, I have basically taken to not building locally anymore.

Do you have any use cases which are not approximately some flavor of:

Our actual internal use case is as follows:

Reproductions steps :

Sorry, we don't offer help diagnosing problems. See Support Resources for a list of what we do and do not offer help with.

I also don't know how to reproduce the problem. I followed the guide found in T10246 to set up DryDock. I reported the bug hoping you could help me diagnosis the problem. How do you limit the number of working copies ?

I can't reproduce this.

I should add that their plans for mid-2016 is to integrate all of this Windows OpenSSH support into the OpenSSH upstream repository, which is likely to be the time that Microsoft declares it production ready.

In T10203#185542, @thoughtpolice wrote:

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Yeah, Appveyor only supports one concurrent build, but that's *more* than OK for us now, at least. Any form of CI on master and our STABLE branches, at least, is better than no CI for Windows.

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

After D16145, Harbormaster should immediately release resources which no remaining (running or queued) build step takes as an input.

In T11153#180624, @epriestley wrote:

You can determine both of these from the harbormaster step dependency tree.

Today, yes, but not if the tree includes custom build steps which allocate resources or if we add "if <condition>, run <another build plan>" or "foreach <item> in <artifact>, run <another build plan with 'item' as an input>". I think these capabilities are probably more interesting than being able to automatically count how many resources a build needs is.

We could do this when a plan is predictable, although an automatic lock acquisition scheme could fail in cases where an explicit one would succeed: for example, when a plan is edited, we may change discovered lock order from "A, B" to "B, A", and builds on the new version of the plan could deadlock with currently-executing builds. If both versions of the plan acquire locks explicitly builds will be able to survive edits.

Generally, I think resource autorelease (using @hach-que's rule) is probably the shortest pathway forward here. You'll still have a fairness problem, but you should get better utilization from the pool and be deadlock-proof on "A", "A" type acquisitions. This also tends to trigger less adjacent work than new resource types would.

Being completely fair also means we must execute without parallelism, because if we start position 2 without waiting for position 1 to finish it might win, and this could keep happening forever.

The expectation is that allocation should generally be fair ("first come, first serve") when no allocations fail.

It's causing a lot of pain mostly because we don't have good visibility into it happening, and we don't have any good way to react to it once we get close to fully saturated.

You can determine both of these from the harbormaster step dependency tree.

You don't really need an explicit release lease to solve this problem. Nor do you need an explicit locking system for resources. You can determine both of these from the harbormaster step dependency tree.

See some prior discussion in T10081, which I'm going to merge here.

Microsoft is providing a way forward here with their implementation of OpenSSH.

For us it would be very helpful to support Windows agents.
We mainly use the phabricator for devops tasks in a microsoft environment. So we develop several powershell frameworks we need to test before deploying them.

This is because that credential is in a restricted Space so this is ultimately the same as T9771, I'm just going to merge it there. The actual Query looks to be implemented fine so I think this is purely a Space issue.

We're no longer (at work) planning or intending on continuing use for EC2 blueprints. If there's anyone else out there that wants this functionality, feel free to re-open this task.

We're no longer (at work) planning or intending on continuing use for EC2 blueprints. If there's anyone else out there that wants this functionality, feel free to re-open this task.

Closing this off as I don't use dynamically allocated hosts any more (it's too much maintenance of custom patches).