@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.
2014-04-09 22:52 GMT+08:00 Nandavar, Divakar Padiyar < [email protected]>: > Hi Jay, > 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. > > Thanks, > Divakar > > -----Original Message----- > From: Jay Pipes [mailto:[email protected]] > Sent: Wednesday, April 09, 2014 6:23 PM > To: [email protected] > Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live > migration with one nova compute > Importance: High > > Hi Juan, thanks for your response. Comments inline. > > On Mon, 2014-04-07 at 10:22 +0200, Juan Manuel Rey wrote: > > Hi, > > > > I'm fairly new to this list, actually this is my first email sent, and > > to OpenStack in general, but I'm not new at all to VMware so I'll try > > to give you my point of view about possible use case here. > > > > Jay you are saying that by using Nova to manage ESXi hosts we don't > > need vCenter because they basically overlap in their capabilities. > > 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). > > 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 > clusters) just so that one particular host management scheduler/platform > (vCenter) can have all of its features exposed to Nova. > > > I agree with you to some extent, Nova may have similar capabilities > > as vCenter Server but as you know OpenStack as a full cloud solution > > adds a lot more features that vCenter lacks, like multitenancy just to > > name one. > > 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. > > > Also in any vSphere environment managing ESXi hosts individually, this > > is without vCenter, is completely out of the question. vCenter is the > > enabler of many vSphere features. And precisely that's is, IMHO, the > > use case of using Nova to manage vCenter to manage vSphere. Without > > vCenter we only have a bunch of hypervisors and none of the HA or DRS > > (dynamic resource balancing) capabilities that a vSphere cluster > > provides, this in my experience with vSphere users/customers is a no > > go scenario. > > Understood. Still doesn't change my opinion though :) > > Best, > -jay > > > I don't know why the decision to manage vCenter with Nova was made but > > based on the above I understand the reasoning. > > > > > > Best, > > --- > > Juan Manuel Rey > > > > @jreypo > > > > > > On Mon, Apr 7, 2014 at 7:20 AM, Jay Pipes <[email protected]> wrote: > > On Sun, 2014-04-06 at 06:59 +0000, Nandavar, Divakar Padiyar > > wrote: > > > >> Well, it seems to me that the problem is the above > > blueprint and the code it introduced. This is an anti-feature > > IMO, and probably the best solution would be to remove the > > above code and go back to having a single >> nova-compute > > managing a single vCenter cluster, not multiple ones. > > > > > > Problem is not introduced by managing multiple clusters from > > single nova-compute proxy node. > > > > > > I strongly disagree. > > > > > Internally this proxy driver is still presenting the > > "compute-node" for each of the cluster its managing. > > > > > > In what way? > > > > > What we need to think about is applicability of the live > > migration use case when a "cluster" is modelled as a compute. > > Since the "cluster" is modelled as a compute, it is assumed > > that a typical use case of live-move is taken care by the > > underlying "cluster" itself. With this there are other > > use cases which are no-op today like host maintenance mode, > > live move, setting instance affinity etc., In order to > > resolve this I was thinking of > > > "A way to expose operations on individual ESX Hosts like > > Putting host in maintenance mode, live move, instance > > affinity etc., by introducing Parent - Child compute node > > concept. Scheduling can be restricted to Parent compute node > > and Child compute node can be used for providing more drill > > down on compute and also enable additional compute > > operations". Any thoughts on this? > > > > > > The fundamental problem is that hacks were put in place in > > order to make > > Nova defer control to vCenter, when the design of Nova and > > vCenter are > > not compatible, and we're paying the price for that right now. > > > > All of the operations you describe above -- putting a host in > > maintenance mode, live-migration of an instance, ensuring a > > new instance > > is launched near or not-near another instance -- depend on a > > fundamental > > design feature in Nova: that a nova-compute worker fully > > controls and > > manages a host that provides a place to put server instances. > > We have > > internal driver interfaces for the *hypervisor*, not for the > > *manager of > > hypervisors*, because, you know, that's what Nova does. > > > > The problem with all of the vCenter stuff is that it is trying > > to say to > > Nova "don't worry, I got this" but unfortunately, Nova wants > > and needs > > to manage these things, not surrender control to a different > > system that > > handles orchestration and scheduling in its own unique way. > > > > If a shop really wants to use vCenter for scheduling and > > orchestration > > of server instances, what exactly is the point of using > > OpenStack Nova > > to begin with? What exactly is the point of trying to use > > OpenStack Nova > > for scheduling and host operations when you've already shelled > > out US > > $6,000 for vCenter Server and a boatload more money for ESX > > licensing? > > > > Sorry, I'm just at a loss why Nova was changed to accomodate > > vCenter > > cluster and management concepts to begin with. I just don't > > understand > > the use case here. > > > > Best, > > -jay > > > > > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
