Hi, The current config template includes a list of "Services which consume this": http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/centralize-config-options.html#quality-view
I propose we drop this list from the template. I am worried this is going to be hard to maintain, and hard to review / check. As such, its of limited use to most deployers in its current form. I have been thinking about a possible future replacement. Two separate sample configuration files, one for the Compute node, and one for non-compute nodes (i.e. "controller" nodes). The reason for this split, is our move towards removing sensitive credentials from compute nodes, etc. Over time, we could prove the split in gate testing, where we look for conf options accessed by computes that shouldn't be, and v.v. Having said that, for newton, I propose we concentrate on: * completing the move of all the conf options (almost there) * (skip tidy up of deprecated options) * tidying up the main description of each conf option * tidy up the Opt group and Opt types, i.e. int min/max, str choices, etc ** move options to use stevedoor, where needed * deprecating ones that are dumb / unused * identifying "required" options (those you have to set) * add config group descriptions * note any surprising dependencies or value meanings (-1 vs 0 etc) * ensure the docs and sample files are complete and correct I am thinking we could copy API ref and add a comment at the top of each file (expecting a separate patch for each step): * fix_opt_registration_consistency (see sfinucan's tread) * fix_opt_description_indentation * check_deprecation_status * check_opt_group_and_type * fix_opt_description Does that sound like a good plan? If so, I can write this up in a wiki page. Thanks, John PS I also have concerns around the related config options bits and possible values bit, but thats a different thread. Lets focus on the main body of the description for now. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
