On 05/20/2016 11:33 AM, John Garbutt wrote:
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.
Unfortunately I still haven't found a way to collect this information in
an automated way. :(
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)
Only one left: https://review.openstack.org/314091
For the sake of completeness, there are two "SubCommandOpt" instances
[1][2] which are purely used for CLI options and are *not* part of the
"nova.conf" file. I think it's best to leave them where they are. All
other config options in "nova/conf/" then share the same behavior of
being configurable by the "nova.conf" file.
* (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.
Yes, sounds good. I can prepare a burndown chart like Sean did for the
api-ref work [3].
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
References:
[1]
https://github.com/openstack/nova/blob/d619ad6ba15df1cf7dc92ddf84d1c65af018682f/nova/cmd/dhcpbridge.py#L92-L92
[2]
https://github.com/openstack/nova/blob/b8aac794d4620aca341b269c6db71ea9e70d2210/nova/cmd/manage.py#L1397-L1397
[3] http://burndown.dague.org/
--
Regards, Markus Zoeller (markus_z)
__________________________________________________________________________
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
