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. _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
