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

2016-06-07 Thread John Garbutt 
On 27 May 2016 at 17:15, Markus Zoeller  wrote:
> On 20.05.2016 11:33, 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.
>>
>> 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
>
>
> I pushed [1] which introduced the flags from above. I reordered them
> from most to least important, which is IMO:
>
> # needs:fix_opt_description
> # needs:check_deprecation_status
> # needs:check_opt_group_and_type
> # needs:fix_opt_description_indentation
> # needs:fix_opt_registration_consistency

This looks good to me:
https://review.openstack.org/#/c/322255/1

sneti (Sujitha) has put together a wiki page to help describe what
each step means:
https://wiki.openstack.org/wiki/ConfigOptionsConsistency

Thanks,
johnthetubaguy

__
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

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

2016-05-27 Thread Markus Zoeller 
On 20.05.2016 11:33, 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.
> 
> 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


I pushed [1] which introduced the flags from above. I reordered them
from most to least important, which is IMO:

# needs:fix_opt_description
# needs:check_deprecation_status
# needs:check_opt_group_and_type
# needs:fix_opt_description_indentation
# needs:fix_opt_registration_consistency


> 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
> 

References:
[1] https://review.openstack.org/#/c/322255/1

-- 
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

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

2016-05-20 Thread Markus Zoeller 

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

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

2016-05-20 Thread Chris Dent 

On Fri, 20 May 2016, John Garbutt wrote:


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.



That would be marvelous and would be a nice step in the direction of
making the compute node more independent. Truly long term it would
be great for reducing cognitive load and increasing contractual
boundaries and strength if nova-compute were in its own repo.


/me dances away from the pragmatists


Does that sound like a good plan? If so, I can write this up in a wiki page.


+1

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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

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

2016-05-20 Thread John Garbutt 
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