On 8 April 2014 11:51, Dan Prince <dpri...@redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Robert Collins" <robe...@robertcollins.net>
>> To: "OpenStack Development Mailing List" <openstack-dev@lists.openstack.org>
>> Sent: Monday, April 7, 2014 4:00:30 PM
>> Subject: [openstack-dev] [TripleO] config options, defaults, oh my!
>>
>> So one interesting thing from the influx of new reviews is lots of
>> patches exposing all the various plumbing bits of OpenStack. This is
>> good in some ways (yay, we can configure more stuff), but in some ways
>> its kindof odd - like - its not clear when
>> https://review.openstack.org/#/c/83122/ is needed.
>>
>> I'm keen to expose things that are really needed, but i'm not sure
>> that /all/ options are needed - what do folk think?
>
> I think we can learn much from some of the more mature configuration
> management tools in the community on this front. Using puppet as an example
> here (although I'm sure other tools may do similar things as well)... Take
> configuration of the Nova API server. There is a direct configuration
> parameter for 'neutron_metadata_proxy_shared_secret' in the Puppet nova::api
> class. This parameter is exposed in the class (sort of the equivalent of a
> TripleO element) directly because it is convenient and many users may want to
> customize the value. There are however hundreds of Nova config options and
> most of them aren't exposed as parameters in the various Nova puppet classes.
> For these it is possible to define a nova_config resource to configure *any*
> nova.conf parameter in an ad hoc style for your own installation tuning
> purposes.
>
> I could see us using a similar model in TripleO where our elements support
> configuring common config elements directly, but we also allow people to tune
> extra "undocumented" options for their own use. There is always going to be a
> need for this as people need to tune things for their own installations with
> options that may not be appropriate for the common set of elements.
>
> Standardizing this mechanism across many of the OpenStack service elements
> would also make a lot of sense. Today we have this for Nova:
>
> nova:
> verbose: False
> - Print more verbose output (set logging level to INFO instead of default
> WARNING level).
> debug: False
> - Print debugging output (set logging level to DEBUG instead of default
> WARNING level).
> baremetal:
> pxe_deploy_timeout: "1200"
> .....
>
> I could see us adding a generic mechanism like this to overlay with the
> existing (documented) data structure:
>
> nova:
> config:
> default.compute_manager:
> ironic.nova.compute.manager.ClusterComputeManager
> cells.driver: nova.cells.rpc_driver.CellsRPCDriver
>
> And in this manner a user might be able to add *any* supported config param
> to the element.
I like this - something like
nova:
config:
- section: default
values:
- option: 'compute_manager'
value: 'ironic.nova.compute.manager.ClusterComputeManager'
- section: cells
values:
- option: 'driver'
value: nova.cells.rpc_driver.CellsRPCDriver
should be able to represent most? all (it can handle repeating items)
oslo.config settings and render it easily:
{{#config}}
{{#comment}} repeats for each section {{/comment}}
[{{section}}]
{{#values}}
{{option}}={{value}}
{{/values}}
{{/config}}
>> Also, some things
>> really should be higher order operations - like the neutron callback
>> to nova right - that should be either set to timeout in nova &
>> configured in neutron, *or* set in both sides appropriately, never
>> one-half or the other.
>>
>> I think we need to sort out our approach here to be systematic quite
>> quickly to deal with these reviews.
>
> I totally agree. I was also planning to email the list about this very issue
> this week :) My email subject was going to be "TripleO templates... an
> upstream maintenance problem".
>
> For the existing reviews today I think we should be somewhat selective about
> what parameters we expose as top level within the elements. That said we are
> missing some rather fundamental features to allow users to configure
> "undocumented" parameters as well. So we need to solve this problem quickly
> because there are certainly some configuration corner that users will need.
>
> As is today we are missing some rather fundamental features in
> os-apply-config and the elements to be able to pull this off. What we really
> need is a generic INI style template generator. Or perhaps we could use
> something like augeus or even devstacks simple ini editing functions to pull
> this off. In any case the idea would be that we allow users to inject their
> own undocumented config parameters into the various service config files. Or
> perhaps we could auto-generate mustache templates based off of the upstream
> sample config files. Many approaches would work here I think...
I agree that there are many approaches here - I think the sketch above
may be sufficient for right now.
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
