I don't think this is a huge deal, but it would be nice to have a safety net in place.

Also, I doubt there is a good solution, just verifying.

Adding Nodir. I think this may be done on buildbucket side but I can't see how on the Swarming side.

what triggers those builds? chromium does not have this problem because such builds are/would be triggered by luci-scheduler which can guarantee that it runs only one bulid at a time. Ideally only luci-scheduler has permissions to schedule builds in such builders, so that's how we solve the problem. Can you use luci-scheduler for this case?

On buildbot it is guaranteed by having one slave attached to the builder. Is this how CrOS solves the problem on buildbot? If so, CrOS can do the same thing on swarmbucket: in builder definition, add "id:<botid>" dimension.

We have a variety of ways to schedule builders:

* LUCI Scheduler
* Master builds schedule slave builds.
* Launch via UI (not yet implemented, I'm expecting safe limits)
* Manual Launch via command line tool.

Manually launching a problematic builder is possible, but would require a user ignore multiple warnings and confirmations.

I only filed this because it would be nice to have a safety net in case something gets out of whack.

current work around: use "id" dimension in the builder configuration to limit the number of machines mapped to the builder

since last comment, luci-scheduler took the responsibility for managing max number of builds of a builder. For example, Chromium's "Builders" (builders that compile) use luci-scheduler to trigger "Testers" (builders that run tests). Luci-scheduler ensures that that the number of simultaneously running builds of a builder is limited (currently the limit is 1).

With this separation of responsibilities, it seems to me that that buildbucket should not grow a similar responsibility. 

The deal breaker for CrOS is that luci-scheduler requires every such job to be defined in a config file and *currently* has no plans to support "dynamic jobs" (like buildbucket api v2 plans to), i.e. you cannot define a job by calling EmitTriggers RPC. This part requires design.

Since last comment, we’ve realized that “Dynamic builders” feature alone won’t solve CrOS-specific problem of complex configurations and high number of buckets, so we need to make enitire configuration set (all files) more dynamic. The current thinking is allow direct config pushes from clients right into luci config. 

This means no more “deal breaker”. This feature exists in luci scheduler