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