Hi Folks, Reviewing some the changes to move control flows into conductor made me wonder about an issue that I haven't seen discussed so far (apologies if it was and I've missed it):
In the original context of using Conductor as a database proxy then the number of conductor instances is directly related to the number of compute hosts I need them to serve. I don't have a fee for what this ratio is (as we haven't switched yet) but based on the discussions in Portland I have the expectation that even with the eventlet performance fix in place there could still need to be 10's for a large deployment. What I not sure is that I would also want to have the same number of conductor instances for task control flow - historically even running 2 schedulers has been a problem, so the thought of having 10's of them makes me very concerned at the moment. However I can't see any way to specialise a conductor to only handle one type of request. So I guess my question is, given that it may have to address two independent scale drivers, is putting task work flow and DB proxy functionality into the same service really the right thing to do - or should there be some separation between them. Don't get me wrong - I'm not against the concept of having the task work flow in a well defined place - just wondering if conductor is really the logical place to do it rather than , for example, making this part of an extended set of functionality for the scheduler (which is already a separate service with its own scaling properties). Thoughts ? Phil
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
