Generic configuration check framework

Registered by Tracy Jones on 2013-11-08

Create a configuration check framework which will check the core service endpoints as well as the hypervisor configuration. This script can be used before starting openstack to verify that the configuration is correct. Initially this will be a nova config check but could be used for other services as well.

Specific to the VC driver - It would also be nice if (perhaps a different scipt) could connect to a given VC and extract the proper configuration for that VC - i.e. the cluster, datastore regex etc

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Shawn Hartsock
Direction:
Needs approval
Assignee:
Shawn Hartsock
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Identified 2 different areas that need attention

* find duplicate or non-existent options in the config.
     This category of issues could be caught with a standalone tool (proof of concept in nova/tools)

2. find an invalid mix of settings
     This should be caught during service startup. http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283

     An idea for creating validation rules per service -

opts = [
 StrOpt('foo_url',
        validate_rule=cfg.MatchesRegexp('(git|http)://')),
]

def validate_proxy_url(conf, group, key, value):
   if not conf.vnc_enabled:
       return
   if conf.ssl_only and value.startswith("http://"):
       raise ValueError('ssl_only option detected, but ...')

opts = [
 StrOpt('novncproxy_base_url',
        validate_rule=validate_proxy_url),
 ...
]

Links to patches which were written to address issues already found

https://bugs.launchpad.net/nova/+bug/1243614
https://review.openstack.org/#/c/53303/

Rubick project (Diagnostics API) adresses the very same problem:
https://launchpad.net/rubick
Let's investigate potential for integration/cross-contribution to this initiative. -ogelbukh

different drivers can add specific validation hooks - for example for the vmware api will check the connection to VC, validate the cluster, ensure there are hosts in the cluster etc.

Requirements - https://etherpad.openstack.org/p/w5BwMtCG6z

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyIdentified 2 different areas that need attention

* find duplicate or non-existent options in the config.
     This category of issues could be caught with a standalone tool (proof of concept in nova/tools)

2. find an invalid mix of settings
     This should be caught during service startup. http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283

     An idea for creating validation rules per service -

opts = [
 StrOpt('foo_url',
        validate_rule=cfg.MatchesRegexp('(git|http)://')),
]

def validate_proxy_url(conf, group, key, value):
   if not conf.vnc_enabled:
       return
   if conf.ssl_only and value.startswith("http://"):
       raise ValueError('ssl_only option detected, but ...')

opts = [
 StrOpt('novncproxy_base_url',
        validate_rule=validate_proxy_url),
 ...
]

Links to patches which were written to address issues already found

https://bugs.launchpad.net/nova/+bug/1243614
https://review.openstack.org/#/c/53303/

Rubick project (Diagnostics API) adresses the very same problem:
https://launchpad.net/rubick
Let's investigate potential for integration/cross-contribution to this initiative. -ogelbukh

different drivers can add specific validation hooks - for example for the vmware api will check the connection to VC, validate the cluster, ensure there are hosts in the cluster etc.

Requirements - https://etherpad.openstack.org/p/w5BwMtCG6z

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.