Open Stack

Hi, 

Thanks for the reply.

Some comments are inlined. 
On Oct 12, 2012, at 5:55 AM, Matt Joyce wrote:

> - Do I need to have nova-api on each compute node? I guess yes. 
> 
>  
> You might want it on another node for HA but it's not at all necessary. 

Ok clear. 
>  
> - What is good practice to run compute node? I mean do I need nova-volume, nova-cert and nova-scheduler on each compute node?   
> 
> You only need nova-compute for ec2 usage on each node.  nova-volume is needed if you intend to create volumes on those nodes.  
> 
> https://github.com/cloudscaling/tarkin  has some simple tests.
> 
> Tempest I hear can do more?

Thanks I will use those.
>  
> 
> - Do I need to create a bridge on the new compute node, when I don't want to run nova-network on that node? I think bridge is only required by the nova-network? But than I get confused with how the network will work? I mean all the traffic of the VMs will go from the node running nova-network? I guess this is not correct right? 
> 
> 
> Depends on how your networking is set up.  But usually a bridge is created for each virtual interface of your instances.  nova-compute will do that for you.

So with this statement should I understand that the bridge is also required/used by nova-compute… right?
In this case I thing the traffic will not route through the node that runs the nova-network…. 

>  
> If all the traffic from VMs will route through the node running nova-network then should I run nova-network on each compute node as well? Or what is the correct way? 
> 
> 
> depends on your networking configuration.   

Can you please explain it a bit. I mean in a very simple scenario, 

node-A, controller node running nova-api, nova-network, nova-scheduler, nova-cert, nova-cert, nova-objectstore, nova-volume 

node-B, only nova-compute 

Will the traffic of the booted instances on node-B will route from node-A or not.




> Thanks in advance. 
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121012/fb5de669/attachment.html>