Open Stack

Hi all,

Rohit (from NTT) and I have been tracking the nova conductor service that is being built and at least I had some questions that the community might be able to answer and/or enlighten us with.

It seems like right now u have been moving the nova-compute DB calls to the message queue calls. This in general seems like a good move for security but has there been any examination of the performance impact this will have in medium -> large clusters? Has there been any plan for said analysis and determination of side effects so that deployers can prepare for said change? I'd just like to avoid a change that could be a big problem later by preemptively determining its effects on the MQ.

After moving some of the compute node calls to the DB to the MQ I was thinking about what happens next.

Personally I would like to see if we can get said conductor MQ calls moved up a layer (so that the compute node doesn't make such calls at all) but instead a layer above it (aka the orchestration layer) invokes said calls 'on-behalf' of the compute node (since said orchestration should ensure all resources can be obtained before attempting to interact with them) and after obtaining said resource the orchestration would form a virtualization 'document' (fully qualified) for the hypervisor to start (+- some acknowledgements of resource usage it will have to send out to claim said resources).

Rohit and I and others at Y! want to make sure that code gets in sometime in the future (it will drastically simplify and centralize the maze that is nova state-transition management currently). It would also allow for  resource rollbacks (more easier to understand retries, the current retry is 'hairy' to say the least), better error messaging, more comprehensive scheduling and the like.

Was wondering you the communities thoughts on this were, since Rohit and I want to make sure we don't go to far astray implementing this.

Thanks all,

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130201/55fc5ece/attachment-0001.html>