Open Stack

@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 <
divakar.padiyar-nandavar at hp.com>:

> 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:jaypipes at gmail.com]
> Sent: Wednesday, April 09, 2014 6:23 PM
> To: openstack-dev at lists.openstack.org
> 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 <jaypipes at gmail.com> 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
> >         OpenStack-dev at lists.openstack.org
> >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/ab1e9d2e/attachment.html>