• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Build Farm Builder Pools

Make pools of builders reserved for usage by different groups of users

As a user of daily builds
I want to make sure the builds are done without undue delay
so that so that the latest builds are available promptly

As an Ubuntu developer
I want to make sure that daily builds don't swamp the build farm
so that regular Ubuntu package builds are not delayed

• Groups of builders may be owned by different teams, e.g. OEM could own a set of armel builders that are exclusively for OEM builds
• Builders may also have an affinity to certain build types
  • Non-exclusivity allows other builds to use those builders when they're idle
  • Build jobs with affinity to those builders will take priority

Rationale

Why are we doing this now?

1. The daily builds project will be coming on line soon and extra hardware will be purchased for its use. We want to make sure that hardware really does get used for daily builds.
2. The OEM team wants a pool of armel builds for its own use

What value does this give our users? Which users?

• This feature ensures that daily builds won't monopolise the build farm over everything else.
• Conversely, it ensures that everything else won't monopolise the build farm to the detriment of daily builds.
• It helps OEM to do timely builds using their own buildd hardware.

Stakeholders

Who really cares about this feature? When did you last talk to them?

• Mark S.
• OEM

Constraints

What MUST the new behaviour provide?

• At the very least, a set of builders exclusively for daily builds.
• OEM must be able to use PPAs to get timely builds of their packages
• Web-based admin control of build pools

What MUST it not do?

Subfeatures

Workflows

• If a Buildd-admin wants to see a list of all the existing pools, he visits /builders/+pools and gets a sortable table showing the pools along with which PPAs are using them. He can then click on a pool name to edit it.

Once on that page there are more actions available:

• Buildd-admin visits /builders/+pools/+new to create a new pool, which redirects after completing to:

• Buildd-admin visits /builders/+pools/<name> to edit or view an existing pool. Editing an existing pool will happen if new builder hardware is bought and needs to be added to a pool.

• OEM engineer or Buildd-admin visits the Archive:+edit page and sees an enabled widget that allows multi-selection of available (i.e. permissioned) pools.

• A buildd-admin visits /builders and clicks on the "pool" column to sort the builders by the pools that they're in.

Need bigger picture for these workflows. e.g. Why would the admin visit /builders/+pools? What are they trying to achieve? What problem are they solving by editing an existing pool? -- jml [2010-04-05]

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.

Success

How will we know when we are done?

• When daily builds will only build on their designated builders and don't cause disruption to the other build types on the build farm
  • What is the measure of the problem right now? How much disruption happens / how often?

How will we measure how well we have done?

• Number of blocked builds goes down, and duration of blockages goes down.

Release Note

XXX

Thoughts?

Put everything else here. Better out than in.

• Everyone agrees that we should rename BuilderPolicy to BuilderPool

• BuilderPool should have an owner so that the same person (or person in the team) can give their PPA access to the builder pool with no admin intervention

• Archives need multiple pools (policies) so that they can access different sets of restricted builders (e.g. different architectures may be added)
• buildd-admins will be responsible for creating the pools and associating builders with them
• Bjorn wonders if the exclusivity flag should be on the builder table or the builderpool table?
• We will restrict who can create daily builds to start with, hence the restrictions on who can give their PPAs access.
• We need to look at fixing determineArchitecturesToBuild() so that it takes pools into account.

jml's questions

Quick type-up of my paper notes, apologies for the terseness.

• Do we want to see queues for pools? It seems natural...

  • Do you mean the queue time summary that we have right now? We could split this up for each pool, but that adds some serious complications when builds may hit more than one pool. --Julian, 2008-04-14

• How will we tell when pools need to grow?

  • That sounds like a subjective opinion by whomever owns the pools - how long an average wait are they prepared to tolerate to get builds done? We already graph build wait times on lpstats. --Julian, 2008-14-14

Regarding /builders/+pools mockup

• [FIXED] There should be some kind of text below the "Builder Pools" heading, I think.
• [FIXED] Do we have a style guide on "Add" vs "Register" in the UI? "Register new pool" seems clunky.

  • /builders has "register, I should fix that too. -- Julian

• "AJAX for editing existing or adding a new pool" -- I'd like to see more on this

  • Michael can sort this out once we get the basic page in place. -- Julian

• [FIXED] What about showing the number of machines in a pool in the table

Regarding /~soyuz-team/+archive/ppa mockup

• "A delta to apply to all build scores for this archive" -- this text is only informative to those already in the know

  • It's on the admin page, plus it's already there, so I don't care right now -- Julian, 2008-04-14

• "Builder Pools To Use"

  • [FIXED] Title case, "Builder pools to use"

  • [FIXED] Should have text here explaining what it's for

Regarding /builders mockup

• "Updated on 11:57:03 GMT" should say by whom. Also, perhaps that should go in the top right.

  • It's an auto-updating page -- Julian, 2008-04-14