On 08/13/2015 05:02 AM, Daniel P. Berrange wrote:
> On Wed, Aug 12, 2015 at 07:20:24PM +0200, Markus Zoeller wrote:
>> Another thing which makes it hard to understand the impact of the config
>> options is, that it's not clear how the interdependency to other config
>> options is. As an example, the "serial_console.base_url" has a
>> dependency to "DEFAULT.cert" and "DEFAULT.key" if you want to use
>> secured websockets ("base_url=wss://..."). Another one is the option
>> "serial_console.serialproxy_port". This port number must be the same
>> as it is in "serial_console.base_url". I couldn't find an explanation to
>> this.
>>
>> The three questions I have with every config option:
>> 1) which service(s) access this option?
>> 2) what does it do? / what's the impact?
>> 3) which other options do I need to tweek to get the described impact?
>>
>> Would it make sense to stage the changes?
>> M cycle: move the config options out of the modules to another place
>> (like the approach Sean proposed) and annotate them with
>> the services which uses them
>> N cycle: inject the options into the drivers and eliminate the global
>> variables this way (like Daniel et al. proposed)
>
> The problem I see is that as long as we're using config options as
> global variables, figuring out which services use which options is
> a major non-trivial effort. Some may be easy to figure out, but
> with many it gets into quite call path analysis, and the usage is
> changing under your feet as new reviews are posted. So personally
> I think it would be more practical todo the reverse. ie stop using
> the config options as global variables, and then split up the
> config file so that we have a separate one for each service.
>
> ie a /etc/nova/nova-compute.conf and get rid of /etc/nova/nova.conf
Options shouldn't be popping back and forth between services that often.
If they are, we're doing something else wrong. I do agree that it's a
big effort to start working through this. But we have some volunteers
and will on it. And in collapsing these options into a smaller number of
places we're going to be touching most of them and getting to ask real
questions like "why is this even a thing?".
Because, right now, I don't think anyone has a good handle on our
configuration space. Providing that global view through such a
reorganization will help us figure out next steps here.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
