Bug 1041452

Summary: [RFE][nova]: VMwareAPI - self-configuration mode for driver(s)
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/nova/+spec/vmwareapi-self-configuring-mode-for-driver
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_new
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 16:56:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 16:10:10 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/vmwareapi-self-configuring-mode-for-driver.

Description:

Driver enhancements in Havana will enable one nova-compute node to dispatch to multiple vCenter clusters. Most of the time vCenter servers need to be configured with compute-clusters that have DRS, auto-placement (very important), and shared datastores. Currently, configuration requires manual construction of nova.conf files with specific knowledge of the vCenter's inventory.

Reverse this dependency! When nova-compute comes up with a valid minimal configuration (url, username, password) a standard set of vCenter conventions should allow nova to *discover* the appropriate inventory inside vCenter. These default conventions should be decided on by the OpenStack community but optional configurations should allow an administrator to override how the conventions work.

Conventions should be customizable following a rule of Convention over Configuration but not to the point of blocking configuration as an option.

For example: 
* default: clusters with the name prefix OS_ should have their resource pools be automatically configured to be OpenStack resources.
* allow overrides so that different name patterns in vCenter can be allocated to different tenants in Nova 
** this would let a vCenter administrator hand over more resources to OpenStack without having to manually register them in configurations
* allow precision configuration (the current mode) when desired

This should compliment work already done in Havana and make OpenStack + vCenter easier to configure and install.

Specification URL (additional information):

None