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
