Open Stack

On 09/24/2013 12:15 PM, James E. Blair wrote:
> 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.

As a follow on to that - in capacity planning, we may also want to look
at how long these tests run. If they run in a fraction of the time of a
devstack/tempest test, then clearly we could still meet changes per
unit-time tested with a lower number of total active build slaves.

That's potentially obvious, but thought I'd point it out.