Open Stack

On 14/07/14 09:34, Vaddi, Kiran Kumar wrote:
> Hi,
> 
>  
> 
> In the Juno summit, it was discussed that the existing approach of
> managing multiple VMware Clusters using a single nova compute service is
> not preferred and the approach of one nova compute service representing
> one cluster should be looked into.
> 
>  
> 
> We would like to retain the existing approach (till we have resolved the
> issues) for the following reasons:
> 
>  
> 
> 1.       Even though a single service is managing all the clusters,
> logically it is still one compute per cluster. To the scheduler each
> cluster is represented as individual computes. Even in the driver each
> cluster is represented separately.
> 
>  
> 
> 2.       Since ESXi does not allow to run nova-compute service on the
> hypervisor unlike KVM, the service has to be run externally on a
> different server. Its easier from administration perspective to manage a
> single service than multiple.
> 
>  
> 
> 3.       Every connection to vCenter uses up ~140MB in the driver. If we
> were to manage each cluster by an individual service the memory consumed
> for 32 clusters will be high (~4GB). The newer versions support 64 clusters!
> 
>  
> 
> 4.       There are existing customer installations that use the existing
> approach and therefore not enforce the new approach until it is simple
> to manage and not resource intensive.
> 
>  
> 
> If the admin wants to use one service per cluster, it can be done with
> the existing driver. In the conf the admin has to specify a single
> cluster instead of a list of clusters. Therefore its better to give the
> admins the choice rather than enforcing one type of deployment.

Does anybody recall the detail of why we wanted to remove this? There
was unease over use of instance's node field in the db, but I don't
recall why.

Matt

-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490