[openstack-dev] [nova] Propose to add FusionCompute driver to Nova

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Oct 13 23:52:20 UTC 2016


On 10/13/2016 4:36 PM, Jay Pipes wrote:
>
> What benefit besides marketing does Huawei get from "integrating"
> FusionCompute with OpenStack? From looking at the wiki page above,
> FusionCompute's product line essentially duplicates a half-dozen or more
> OpenStack services, including Nova's scheduler, Nova's compute workers,
> Nova's administrative APIs, Neutron, Cinder, Designate, Octavia,
> Barbican, and Heat in a monolithic single cloud management application.
>
> What technical benefit do you see from writing a Nova virt driver that
> calls the Huawei Compute Management Agent, which then calls the Huawei
> Virtual Resource Manager clustered resource management system?
>
> Best,
> -jay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

That's basically describing the PowerVC driver that is in what used to 
be called stackforge:

http://git.openstack.org/cgit/openstack/powervc-driver/tree/nova-powervc/

It's a virt driver that talks to PowerVC's API, which is basically like 
a vCenter for Power systems. I think the point was you could have a 
vanilla openstack distribution and drop this driver in to talk to your 
PowerVC deployment, but why you'd do that rather than just use PowerVC 
directly I'm not sure, except maybe a 'hybrid' virt driver environment 
where you have some KVM, some vCenter, some HyperV and some PowerVC. I'm 
guessing the same argument could be made for the Huawei driver, and we'd 
likely reject it for the same reasons - it's really a cluster driver 
that talks to a virt manager and we really don't want any more cluster 
drivers in tree, especially single-vendor ones to proprietary backends.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list