[openstack-dev] [nova] Centralize Configuration: ignore service list for newton

Markus Zoeller mzoeller at linux.vnet.ibm.com
Fri May 20 11:56:27 UTC 2016


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-request at 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)




More information about the OpenStack-dev mailing list