<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><div><div>On Nov 12, 2012, at 1:12 PM, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">And fwiw I think the plan of starting small with db writes and building up us the right one. But I wonder about the requirement of a new service. For cleanliness I like separating into a new service but for ease of deployment it seems far easier to make this a part of nova-scheduler.</p>
</blockquote><div><br></div><div><div>If it's something that is modularized well enough to make it optional to run as a separate service, I think this makes sense for (the more common case of) smaller deployments, and have nova-scheduler be the default.</div><div><br></div><div>As a side note, we really need to get DB writes non-blocking again, preferably ahead of any changes to move DB updates over to a single service. As it stands, moving the DB updates to a single service is going to completely serialize all DB calls that are currently distributed across many nova-computes. I can attest to there being a huge performance issue when doing this, as nova-cells at the global level essentially has this functionality. It's largely a DB writer… and at Rackspace scale, it's doing quite a bit of writes. Because there's so many DB calls going on, it tends to affect its ability to simply route messages. The DB calls blocking steal a lot of time where other work can be happening. So, if you're going to move this to the scheduler, that's something to consider, also.</div><div><br></div><div>- Chris</div><div><br></div><div><br></div><div><br></div></div><div><br></div></div></div></body></html>