Open Stack

Robert,

Thank you for the excellent write up.  I believe I understand in general
how this will work, and I agree with you about the non-technical aspects
(how to diversify and maintain this system in the long run).

Without getting too far into details, some of which may be better left
for a time closer to implementation, here are a few thoughts:

My understanding (particularly with Monty's revision of Plan C in the
etherpad) is that nodepool will be used to spin up Jenkins slaves on the
overcloud, and those slaves will build images and communicate with the
resource broker.  We would cap the maximum number of nodes for this
nodepool provider to be the number of available test environments (so
that at max usage, we would have one jenkins slave node per test
environment).  Is that correct?

Regarding the math on the number of test resources currently in use -- I
just implemented a new scheduler for Zuul which is far more ruthless in
its use of test resources.  It now attempts to ensure that all jobs for
all changes that it knows about are running at all times, and as a
result, is likely to be far more aggressive in canceling and restarting
jobs.  Overall resource usage should increase, as well as turnover due
to resetting tests as changes fail.  We should have a better handle on
how it behaves soon.  We should keep an eye on that and adjust
expectations accordingly.  But our general trend at the moment is to
push our clouds even harder to increase utility to developers (and add
more cloud resources as needed).  So over-provisioning (or have a
near-term plan for expansion) may be a good idea.  Anyway, like I said,
we should have real numbers soon.

-Jim