Open Stack

On 8 April 2014 11:51, Dan Prince <dprince at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Robert Collins" <robertc at robertcollins.net>
>> To: "OpenStack Development Mailing List" <openstack-dev at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud