Open Stack

Hi Divakar,

Can I say that the bare metal provisioning is now using kind of "Parent -
Child compute" mode? I was also thinking that we can use host:node to
identify a kind of "Parent-Child" or "Hierarchy Compute". So can you please
show some difference for your "Parent - Child Compute Node" and bare metal
provisioning?

Thanks!


2014-04-06 14:59 GMT+08:00 Nandavar, Divakar Padiyar <
divakar.padiyar-nandavar at hp.com>:

> >> 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.  Internally this proxy driver is still presenting
> the "compute-node" for each of the cluster its managing.    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?
>
> Thanks,
> Divakar
>
>
> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Sunday, April 06, 2014 2:02 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live
> migration with one nova compute
> Importance: High
>
> On Fri, 2014-04-04 at 13:30 +0800, Jay Lau wrote:
> >
> >
> >
> > 2014-04-04 12:46 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:
> >         On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:
> >         > Thanks Jay and Chris for the comments!
> >         >
> >         > @Jay Pipes, I think that we still need to enable "one nova
> >         compute
> >         > live migration" as one nova compute can manage multiple
> >         clusters and
> >         > VMs can be migrated between those clusters managed by one
> >         nova
> >         > compute.
> >
> >
> >         Why, though? That is what I am asking... seems to me like this
> >         is an
> >         anti-feature. What benefit does the user get from moving an
> >         instance
> >         from one VCenter cluster to another VCenter cluster if the two
> >         clusters
> >         are on the same physical machine?
> > @Jay Pipes, for VMWare, one physical machine (ESX server) can only
> > belong to one VCenter cluster, so we may have following scenarios.
> >
> > DC
> >  |
> >
> >  |---Cluster1
> >  |      |
> >
> >  |      |---host1
> >  |
> >
> >  |---Cluser2
> >         |
> >
> >         |---host2
> >
> >
> > Then when using VCDriver, I can use one nova compute manage both
> > Cluster1 and Cluster2, this caused me cannot migrate VM from host2 to
> > host1 ;-(
> >
> >
> > The bp was introduced by
> > https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-
> > by-one-service
>
> 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.
>
> -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
>



-- 
Thanks,

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