A few times now we've run into patches for devstack-gate / devstack that change default configuration to handle 'tempest load'.
For instance - https://review.openstack.org/61137 (Sorry Salvatore I'm not picking on you really!) So there appears to be a meme that the gate is particularly stressful - a bad environment - and that real world situations have less load. This could happen a few ways: (a) deployers might separate out components more; (b) they might have faster machines; (c) they might have less concurrent activity. (a) - unlikely! Deployers will cram stuff together as much as they can to save overheads. Big clouds will have components split out - yes, but they will also have correspondingly more load to drive that split out. (b) Perhaps, but not orders of magnitude faster, the clouds we run on are running on fairly recent hardware, and by using big instances we don't get crammed it with that many other tenants. (c) Almost certainly not. Tempest currently does a maximum of four concurrent requests. A small business cloud could easily have 5 or 6 people making concurrent requests from time to time, and bigger but not huge clouds will certainly have that. Their /average/ rate of API requests may be much lower, but when they point service orchestration tools at it -- particularly tools that walk their dependencies in parallel - load is going to be much much higher than what we generate with Tempest. tl;dr : if we need to change a config file setting in devstack-gate or devstack *other than* setting up the specific scenario, think thrice - should it be a production default and set in the relevant projects default config setting. Cheers, Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev