<div dir="ltr">@Divakar, yes, the "Proxy Compute" model is not new, but I'm not sure if this model can be accepted by community to manage both VM and PM. Anyway, I will try to file a bp and get more comments then. Thanks.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-09 22:52 GMT+08:00 Nandavar, Divakar Padiyar <span dir="ltr"><<a href="mailto:divakar.padiyar-nandavar@hp.com" target="_blank">divakar.padiyar-nandavar@hp.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jay,<br>
Managing multiple clusters using the "Compute Proxy" is not new right? Prior to this "nova baremetal" driver has used this model already. Also this "Proxy Compute" model gives flexibility to deploy as many computes required based on the requirement. For example, one can setup one proxy compute node to manage a set of clusters and another proxy compute to manage a separate set of clusters or launch compute node for each of the clusters.<br>
<div class="im HOEnZb"><br>
Thanks,<br>
Divakar<br>
<br>
-----Original Message-----<br>
From: Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
</div><div class="im HOEnZb">Sent: Wednesday, April 09, 2014 6:23 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute<br>
Importance: High<br>
<br>
</div><div class="HOEnZb"><div class="h5">Hi Juan, thanks for your response. Comments inline.<br>
<br>
On Mon, 2014-04-07 at 10:22 +0200, Juan Manuel Rey wrote:<br>
> Hi,<br>
><br>
> I'm fairly new to this list, actually this is my first email sent, and<br>
> to OpenStack in general, but I'm not new at all to VMware so I'll try<br>
> to give you my point of view about possible use case here.<br>
><br>
> Jay you are saying that by using Nova to manage ESXi hosts we don't<br>
> need vCenter because they basically overlap in their capabilities.<br>
<br>
Actually, no, this is not my main point. My main point is that Nova should not change its architecture to fit the needs of one particular host management platform (vCenter).<br>
<br>
Nova should, as much as possible, communicate with vCenter to perform some operations -- in the same way that Nova communicates with KVM or XenServer to perform some operations. But Nova should not be re-architected (and I believe that is what has gone on here with the code change to have one nova-compute worker talking to multiple vCenter<br>
clusters) just so that one particular host management scheduler/platform<br>
(vCenter) can have all of its features exposed to Nova.<br>
<br>
> I agree with you to some extent, Nova may have similar capabilities<br>
> as vCenter Server but as you know OpenStack as a full cloud solution<br>
> adds a lot more features that vCenter lacks, like multitenancy just to<br>
> name one.<br>
<br>
Sure, however, my point is that Nova shouldn't need to be re-architected just to adhere to one particular host management platform's concepts of an atomic provider of compute resources.<br>
<br>
> Also in any vSphere environment managing ESXi hosts individually, this<br>
> is without vCenter, is completely out of the question. vCenter is the<br>
> enabler of many vSphere features. And precisely that's is, IMHO, the<br>
> use case of using Nova to manage vCenter to manage vSphere. Without<br>
> vCenter we only have a bunch of hypervisors and none of the HA or DRS<br>
> (dynamic resource balancing) capabilities that a vSphere cluster<br>
> provides, this in my experience with vSphere users/customers is a no<br>
> go scenario.<br>
<br>
Understood. Still doesn't change my opinion though :)<br>
<br>
Best,<br>
-jay<br>
<br>
> I don't know why the decision to manage vCenter with Nova was made but<br>
> based on the above I understand the reasoning.<br>
><br>
><br>
> Best,<br>
> ---<br>
> Juan Manuel Rey<br>
><br>
> @jreypo<br>
><br>
><br>
> On Mon, Apr 7, 2014 at 7:20 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
> On Sun, 2014-04-06 at 06:59 +0000, Nandavar, Divakar Padiyar<br>
> wrote:<br>
> > >> Well, it seems to me that the problem is the above<br>
> blueprint and the code it introduced. This is an anti-feature<br>
> IMO, and probably the best solution would be to remove the<br>
> above code and go back to having a single >> nova-compute<br>
> managing a single vCenter cluster, not multiple ones.<br>
> ><br>
> > Problem is not introduced by managing multiple clusters from<br>
> single nova-compute proxy node.<br>
><br>
><br>
> I strongly disagree.<br>
><br>
> > Internally this proxy driver is still presenting the<br>
> "compute-node" for each of the cluster its managing.<br>
><br>
><br>
> In what way?<br>
><br>
> > What we need to think about is applicability of the live<br>
> migration use case when a "cluster" is modelled as a compute.<br>
> Since the "cluster" is modelled as a compute, it is assumed<br>
> that a typical use case of live-move is taken care by the<br>
> underlying "cluster" itself. With this there are other<br>
> use cases which are no-op today like host maintenance mode,<br>
> live move, setting instance affinity etc., In order to<br>
> resolve this I was thinking of<br>
> > "A way to expose operations on individual ESX Hosts like<br>
> Putting host in maintenance mode, live move, instance<br>
> affinity etc., by introducing Parent - Child compute node<br>
> concept. Scheduling can be restricted to Parent compute node<br>
> and Child compute node can be used for providing more drill<br>
> down on compute and also enable additional compute<br>
> operations". Any thoughts on this?<br>
><br>
><br>
> The fundamental problem is that hacks were put in place in<br>
> order to make<br>
> Nova defer control to vCenter, when the design of Nova and<br>
> vCenter are<br>
> not compatible, and we're paying the price for that right now.<br>
><br>
> All of the operations you describe above -- putting a host in<br>
> maintenance mode, live-migration of an instance, ensuring a<br>
> new instance<br>
> is launched near or not-near another instance -- depend on a<br>
> fundamental<br>
> design feature in Nova: that a nova-compute worker fully<br>
> controls and<br>
> manages a host that provides a place to put server instances.<br>
> We have<br>
> internal driver interfaces for the *hypervisor*, not for the<br>
> *manager of<br>
> hypervisors*, because, you know, that's what Nova does.<br>
><br>
> The problem with all of the vCenter stuff is that it is trying<br>
> to say to<br>
> Nova "don't worry, I got this" but unfortunately, Nova wants<br>
> and needs<br>
> to manage these things, not surrender control to a different<br>
> system that<br>
> handles orchestration and scheduling in its own unique way.<br>
><br>
> If a shop really wants to use vCenter for scheduling and<br>
> orchestration<br>
> of server instances, what exactly is the point of using<br>
> OpenStack Nova<br>
> to begin with? What exactly is the point of trying to use<br>
> OpenStack Nova<br>
> for scheduling and host operations when you've already shelled<br>
> out US<br>
> $6,000 for vCenter Server and a boatload more money for ESX<br>
> licensing?<br>
><br>
> Sorry, I'm just at a loss why Nova was changed to accomodate<br>
> vCenter<br>
> cluster and management concepts to begin with. I just don't<br>
> understand<br>
> the use case here.<br>
><br>
> Best,<br>
> -jay<br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>