You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Damien Katz <da...@gmail.com> on 2008/04/10 22:02:18 UTC
server configuration stuff
Currently that CouchDB handles configuration stuff is to reads in it's
configuration setting at startup time the couch.ini file, and then
feeds those settings as startup arguments to the various child servers
processes. This requires that to change a setting you must restart to
take effect.
This is fine for now, but we can do better. I'd like to enhance this
by providing a configuration module that allows for configuration
settings to be changed at runtime, and automatically have those
changes take effect without requiring a server restart.
The way I was thinking it would work, at startup the server
configuration module sucks up the settings from the couch.ini, then
the child processes are started normally, but without startup
arguments. The child processes then query the runtime module at
startup, or whenever, to get their configuration data.
It should be possible for the core modules to subscribe notifications
of configuration updates. In Erlang, this is typically done by the
modules registering a callback function. So when a configuration
setting is updated, it would get invoked with the changed settings as
arguments.
And when a configuration setting is changed at runtime, the module
should write the new setting back to the couch.ini file. And it should
be able to handle updates to settings, etc, and ideally still preserve
all previous formatting and comments.
So, some questions. What do people think of this in general? Or should
we be using the apache conf format instead of ini? Maybe we should use
json?
One things I'd like to see is that configuration stuff be editable in
a text editor. However, I might be dissuaded to start using a CouchDB
database to store everything but the most critical startup information.
Thoughts please.
Re: server configuration stuff
Posted by Jan Lehnardt <ja...@apache.org>.
Heya,
On Apr 10, 2008, at 22:02, Damien Katz wrote:
> Currently that CouchDB handles configuration stuff is to reads in
> it's configuration setting at startup time the couch.ini file, and
> then feeds those settings as startup arguments to the various child
> servers processes. This requires that to change a setting you must
> restart to take effect.
>
> This is fine for now, but we can do better. I'd like to enhance this
> by providing a configuration module that allows for configuration
> settings to be changed at runtime, and automatically have those
> changes take effect without requiring a server restart.
I generally agree, that we can do better and I am very much in favour
of runtime configuration changes. I still need to make up my mind on
how to do that.
> The way I was thinking it would work, at startup the server
> configuration module sucks up the settings from the couch.ini, then
> the child processes are started normally, but without startup
> arguments. The child processes then query the runtime module at
> startup, or whenever, to get their configuration data.
The first question I guess is, if we want to continue to use couch.ini
(or some other configuration file) or if we want to, for example,
start storing the configuration inside a couchdb document. The
document would make it easy (easier?) to integrate configuration into
Futon, our admin client and other software that wants to configure
CouchDB.
A configuration file still feels more robust, though. In case a
configuration setting would prevent the server from starting, you
would actually be able to change that setting (Maybe that is just me
coming from a background with less robust software). Or there are
settings that need to be known before CouchDB can launch.
> It should be possible for the core modules to subscribe
> notifications of configuration updates. In Erlang, this is typically
> done by the modules registering a callback function. So when a
> configuration setting is updated, it would get invoked with the
> changed settings as arguments.
That sounds about right.
> And when a configuration setting is changed at runtime, the module
> should write the new setting back to the couch.ini file. And it
> should be able to handle updates to settings, etc, and ideally still
> preserve all previous formatting and comments.
I'm not very comfortable with changing the config file
programmatically. In that case I'd want to be able to validate its
structure after a change to make sure nothing broke (and I am not
suggesting XML here). On the other hand, if we can make that reliable,
I might feel better.
> So, some questions. What do people think of this in general? Or
> should we be using the apache conf format instead of ini? Maybe we
> should use json?
The use of JSON sounds nice as it removes a possibly tedious and error
prone parsing and generating step for the config module and I think
JSON is enough of a plaintext format to qualify for a configuration
file. People dealing with CouchDB would need to know JSON anyway and
for those who don't it is easy enough to read.
> One things I'd like to see is that configuration stuff be editable
> in a text editor. However, I might be dissuaded to start using a
> CouchDB database to store everything but the most critical startup
> information.
Like I said above, this would be okay if we can guarantee that CouchDB
would launch always to the point that we can reconfigure the config
database in case of problems.
Cheers
Jan
--
Re: server configuration stuff
Posted by Jan Lehnardt <ja...@apache.org>.
On Apr 11, 2008, at 12:54, Noah Slater wrote:
>
>> I'm not very comfortable with changing the config file
>> programmatically. In
>> that case I'd want to be able to validate its structure after a
>> change to make
>> sure nothing broke (and I am not suggesting XML here). On the other
>> hand, if
>> we can make that reliable, I might feel better.
>
> See above example of a Python library that can parse, serialise and
> validate INI
> style configuration files. I am sure that similar libraries must
> exist for other
> languages.
If we can find or port this to Erlang: Very cool :) I'd rather not
introduce a dependency on Python (or any other language for that
matter).
>> The use of JSON sounds nice as it removes a possibly tedious and
>> error prone
>> parsing and generating step for the config module and I think JSON
>> is enough
>> of a plaintext format to qualify for a configuration file. People
>> dealing
>> with CouchDB would need to know JSON anyway and for those who don't
>> it is easy
>> enough to read.
>
> As I mentioned before, the INI style configuration is a de facto
> standard and we
> should use it if we can for that reason alone
I'm personally not seeing INI files as a de facto standard, but I
don't care either way as long as things are robust on easy to use. If
INI does that job, it is very welcome.
> I think it is a false argument to suggest that people dealing with
> CouchDB need
> to know JSON - any corporate database will have many people all
> interacting with
> it at various levels. You can't expect the system administrators to
> know or care
> about JSON or to want to use a web based interface for configuration.
Hence my sentence finished with: "… and for those who don't it is easy
enough to read." Any junior DBA should be able to read a key-value
list marked up in JSON. But as cleared on IRC, we are in violent
agreement here.
Cheers
Jan
--
Re: server configuration stuff
Posted by Jan Lehnardt <ja...@apache.org>.
On Apr 11, 2008, at 12:54, Noah Slater wrote:
>
>> I'm not very comfortable with changing the config file
>> programmatically. In
>> that case I'd want to be able to validate its structure after a
>> change to make
>> sure nothing broke (and I am not suggesting XML here). On the other
>> hand, if
>> we can make that reliable, I might feel better.
>
> See above example of a Python library that can parse, serialise and
> validate INI
> style configuration files. I am sure that similar libraries must
> exist for other
> languages.
If we can find or port this to Erlang: Very cool :) I'd rather not
introduce a dependency on Python (or any other language for that
matter).
>> The use of JSON sounds nice as it removes a possibly tedious and
>> error prone
>> parsing and generating step for the config module and I think JSON
>> is enough
>> of a plaintext format to qualify for a configuration file. People
>> dealing
>> with CouchDB would need to know JSON anyway and for those who don't
>> it is easy
>> enough to read.
>
> As I mentioned before, the INI style configuration is a de facto
> standard and we
> should use it if we can for that reason alone
I'm personally not seeing INI files as a de facto standard, but I
don't care either way as long as things are robust on easy to use. If
INI does that job, it is very welcome.
> I think it is a false argument to suggest that people dealing with
> CouchDB need
> to know JSON - any corporate database will have many people all
> interacting with
> it at various levels. You can't expect the system administrators to
> know or care
> about JSON or to want to use a web based interface for configuration.
Hence my sentence finished with: "… and for those who don't it is easy
enough to read." Any junior DBA should be able to read a key-value
list marked up in JSON. But as cleared on IRC, we are in violent
agreement here.
Cheers
Jan
--
Re: server configuration stuff
Posted by Noah Slater <ns...@apache.org>.
On Thu, Apr 10, 2008 at 04:02:18PM -0400, Damien Katz wrote:
> This is fine for now, but we can do better. I'd like to enhance this by
> providing a configuration module that allows for configuration settings to be
> changed at runtime, and automatically have those changes take effect without
> requiring a server restart.
This sounds like a good idea.
The usual way to do this would be to send a SIGHUP to the daemon telling it to
re-read in it's configuration files. As discussed on IRC, I do not think any
automatic reloads of configuration is wise because:
* the configuration may sit on a network/unstable filesystem which could
produce read errors that could confuse or kill CouchDB
* the configuration could not be edited by a administrator while CouchDB was
running as the server would reload after every save to the file
* automatic packaging systems may overwrite configuration files before the
administrator has time to revert them (happened to me a few times)
> And when a configuration setting is changed at runtime, the module should
> write the new setting back to the couch.ini file. And it should be able to
> handle updates to settings, etc, and ideally still preserve all previous
> formatting and comments.
Are you suggesting a Web based configuration editor in Futon or similar?
Sounds like a pretty nice idea to me.
Writing out to INI files seems simple enough and I know of at least one Python
library that is designed to handle exactly this situation:
http://www.voidspace.org.uk/python/configobj.html
INI files also have the benefit (over say Apache httpd style) of being a
de facto standard, which will help us exploit any 3rd party tools.
On Thu, Apr 10, 2008 at 11:25:02PM +0200, Jan Lehnardt wrote:
> The first question I guess is, if we want to continue to use couch.ini (or
> some other configuration file) or if we want to, for example, start storing
> the configuration inside a couchdb document.
I think this is a bad idea for several reasons.
Storing the database configuration in the database brings some rather bizarre
chicken and egg scenarios of not being able to configure the database, fix a
problem, troubleshoot or tweak without actually running the database:
* you've just installed CouchDB but it won't start, you're now unable to edit
the configuration
* your site is under high load, CouchDB is unresponsive and you quickly need to
reconfigure the database and get things back on track, but you can't because
to configure the database you need it running and it immediately gets bogged
down with incoming queries
* something screwed up with the database and you need to point CouchDB at an
old backup version you have, but you can't because the database wont start
* You're a system administrator and get a phone call in the middle of the
night, the corporate CouchDB instance has gone down and you need to fix
it. You only have access to the production machines via SSH from home,
the web interface is only available on the company's Intranet. You need to
edit the configuration to get things running again, but you can't from the
terminal because you don't have a text-mode browser installed.
> I'm not very comfortable with changing the config file programmatically. In
> that case I'd want to be able to validate its structure after a change to make
> sure nothing broke (and I am not suggesting XML here). On the other hand, if
> we can make that reliable, I might feel better.
See above example of a Python library that can parse, serialise and validate INI
style configuration files. I am sure that similar libraries must exist for other
languages.
> The use of JSON sounds nice as it removes a possibly tedious and error prone
> parsing and generating step for the config module and I think JSON is enough
> of a plaintext format to qualify for a configuration file. People dealing
> with CouchDB would need to know JSON anyway and for those who don't it is easy
> enough to read.
As I mentioned before, the INI style configuration is a de facto standard and we
should use it if we can for that reason alone.
I think it is a false argument to suggest that people dealing with CouchDB need
to know JSON - any corporate database will have many people all interacting with
it at various levels. You can't expect the system administrators to know or care
about JSON or to want to use a web based interface for configuration.
On Apr 10, 2008, at 4:22 PM, Daniel Yokomizo wrote:
> IME it's better to keep config files away from the core of some
> application and let some external agent interpret the files and
> configure the application using an api.
This smells like over engineering or YAGNI to me. :)
--
Noah Slater - The Apache Software Foundation <http://www.apache.org/>
Re: server configuration stuff
Posted by Jan Lehnardt <ja...@apache.org>.
Heya,
On Apr 10, 2008, at 22:02, Damien Katz wrote:
> Currently that CouchDB handles configuration stuff is to reads in
> it's configuration setting at startup time the couch.ini file, and
> then feeds those settings as startup arguments to the various child
> servers processes. This requires that to change a setting you must
> restart to take effect.
>
> This is fine for now, but we can do better. I'd like to enhance this
> by providing a configuration module that allows for configuration
> settings to be changed at runtime, and automatically have those
> changes take effect without requiring a server restart.
I generally agree, that we can do better and I am very much in favour
of runtime configuration changes. I still need to make up my mind on
how to do that.
> The way I was thinking it would work, at startup the server
> configuration module sucks up the settings from the couch.ini, then
> the child processes are started normally, but without startup
> arguments. The child processes then query the runtime module at
> startup, or whenever, to get their configuration data.
The first question I guess is, if we want to continue to use couch.ini
(or some other configuration file) or if we want to, for example,
start storing the configuration inside a couchdb document. The
document would make it easy (easier?) to integrate configuration into
Futon, our admin client and other software that wants to configure
CouchDB.
A configuration file still feels more robust, though. In case a
configuration setting would prevent the server from starting, you
would actually be able to change that setting (Maybe that is just me
coming from a background with less robust software). Or there are
settings that need to be known before CouchDB can launch.
> It should be possible for the core modules to subscribe
> notifications of configuration updates. In Erlang, this is typically
> done by the modules registering a callback function. So when a
> configuration setting is updated, it would get invoked with the
> changed settings as arguments.
That sounds about right.
> And when a configuration setting is changed at runtime, the module
> should write the new setting back to the couch.ini file. And it
> should be able to handle updates to settings, etc, and ideally still
> preserve all previous formatting and comments.
I'm not very comfortable with changing the config file
programmatically. In that case I'd want to be able to validate its
structure after a change to make sure nothing broke (and I am not
suggesting XML here). On the other hand, if we can make that reliable,
I might feel better.
> So, some questions. What do people think of this in general? Or
> should we be using the apache conf format instead of ini? Maybe we
> should use json?
The use of JSON sounds nice as it removes a possibly tedious and error
prone parsing and generating step for the config module and I think
JSON is enough of a plaintext format to qualify for a configuration
file. People dealing with CouchDB would need to know JSON anyway and
for those who don't it is easy enough to read.
> One things I'd like to see is that configuration stuff be editable
> in a text editor. However, I might be dissuaded to start using a
> CouchDB database to store everything but the most critical startup
> information.
Like I said above, this would be okay if we can guarantee that CouchDB
would launch always to the point that we can reconfigure the config
database in case of problems.
Cheers
Jan
--
Re: server configuration stuff
Posted by Noah Slater <ns...@apache.org>.
On Thu, Apr 10, 2008 at 04:02:18PM -0400, Damien Katz wrote:
> This is fine for now, but we can do better. I'd like to enhance this by
> providing a configuration module that allows for configuration settings to be
> changed at runtime, and automatically have those changes take effect without
> requiring a server restart.
This sounds like a good idea.
The usual way to do this would be to send a SIGHUP to the daemon telling it to
re-read in it's configuration files. As discussed on IRC, I do not think any
automatic reloads of configuration is wise because:
* the configuration may sit on a network/unstable filesystem which could
produce read errors that could confuse or kill CouchDB
* the configuration could not be edited by a administrator while CouchDB was
running as the server would reload after every save to the file
* automatic packaging systems may overwrite configuration files before the
administrator has time to revert them (happened to me a few times)
> And when a configuration setting is changed at runtime, the module should
> write the new setting back to the couch.ini file. And it should be able to
> handle updates to settings, etc, and ideally still preserve all previous
> formatting and comments.
Are you suggesting a Web based configuration editor in Futon or similar?
Sounds like a pretty nice idea to me.
Writing out to INI files seems simple enough and I know of at least one Python
library that is designed to handle exactly this situation:
http://www.voidspace.org.uk/python/configobj.html
INI files also have the benefit (over say Apache httpd style) of being a
de facto standard, which will help us exploit any 3rd party tools.
On Thu, Apr 10, 2008 at 11:25:02PM +0200, Jan Lehnardt wrote:
> The first question I guess is, if we want to continue to use couch.ini (or
> some other configuration file) or if we want to, for example, start storing
> the configuration inside a couchdb document.
I think this is a bad idea for several reasons.
Storing the database configuration in the database brings some rather bizarre
chicken and egg scenarios of not being able to configure the database, fix a
problem, troubleshoot or tweak without actually running the database:
* you've just installed CouchDB but it won't start, you're now unable to edit
the configuration
* your site is under high load, CouchDB is unresponsive and you quickly need to
reconfigure the database and get things back on track, but you can't because
to configure the database you need it running and it immediately gets bogged
down with incoming queries
* something screwed up with the database and you need to point CouchDB at an
old backup version you have, but you can't because the database wont start
* You're a system administrator and get a phone call in the middle of the
night, the corporate CouchDB instance has gone down and you need to fix
it. You only have access to the production machines via SSH from home,
the web interface is only available on the company's Intranet. You need to
edit the configuration to get things running again, but you can't from the
terminal because you don't have a text-mode browser installed.
> I'm not very comfortable with changing the config file programmatically. In
> that case I'd want to be able to validate its structure after a change to make
> sure nothing broke (and I am not suggesting XML here). On the other hand, if
> we can make that reliable, I might feel better.
See above example of a Python library that can parse, serialise and validate INI
style configuration files. I am sure that similar libraries must exist for other
languages.
> The use of JSON sounds nice as it removes a possibly tedious and error prone
> parsing and generating step for the config module and I think JSON is enough
> of a plaintext format to qualify for a configuration file. People dealing
> with CouchDB would need to know JSON anyway and for those who don't it is easy
> enough to read.
As I mentioned before, the INI style configuration is a de facto standard and we
should use it if we can for that reason alone.
I think it is a false argument to suggest that people dealing with CouchDB need
to know JSON - any corporate database will have many people all interacting with
it at various levels. You can't expect the system administrators to know or care
about JSON or to want to use a web based interface for configuration.
On Apr 10, 2008, at 4:22 PM, Daniel Yokomizo wrote:
> IME it's better to keep config files away from the core of some
> application and let some external agent interpret the files and
> configure the application using an api.
This smells like over engineering or YAGNI to me. :)
--
Noah Slater - The Apache Software Foundation <http://www.apache.org/>
Re: server configuration stuff
Posted by Daniel Yokomizo <da...@gmail.com>.
On Thu, Apr 10, 2008 at 5:42 PM, Damien Katz <da...@gmail.com> wrote:
>
> On Apr 10, 2008, at 4:22 PM, Daniel Yokomizo wrote:
>
> > A couple of thoughts.
> >
> > 1. Why not use the usual Erlang approach for code update, using the
> > loop for receiving messages and handling config updates, it seems
> > cleaner and a better fit. This way you need only a single process to
> > handle the config file format and notify the rest.
> >
> >
>
> That's pretty much what I was describing. By registering a callback with
> the config module, you can send yourself a message when a relevant change
> takes effect, then act on it.
I didn't understood correctly what you wrote. The idea of "the
modules registering a callback function" seemed odd to me, but now I
see that we are essentially saying the same thing. For more details
see my response to Jan, but I think we agree with each other.
> > 2. Also it would be simpler to have almost every config inside a
> > CouchDB database, so you startup using the default config and the
> > config process reads the database for the real config info and
> > notifies the other modules of the actual values. With this in place
> > it'll be easier to have other config formats in the future: just make
> > some module that understands format foo and writes/reads it to/from
> > couchdb. The config process will see the changes and propagate them.
> >
>
>
> >
> >
> > IME it's better to keep config files away from the core of some
> > application and let some external agent interpret the files and
> > configure the application using an api.
> >
>
> Interesting.
Best regards,
Daniel Yokomizo.
Re: server configuration stuff
Posted by Damien Katz <da...@gmail.com>.
On Apr 10, 2008, at 4:22 PM, Daniel Yokomizo wrote:
> A couple of thoughts.
>
> 1. Why not use the usual Erlang approach for code update, using the
> loop for receiving messages and handling config updates, it seems
> cleaner and a better fit. This way you need only a single process to
> handle the config file format and notify the rest.
>
That's pretty much what I was describing. By registering a callback
with the config module, you can send yourself a message when a
relevant change takes effect, then act on it.
> 2. Also it would be simpler to have almost every config inside a
> CouchDB database, so you startup using the default config and the
> config process reads the database for the real config info and
> notifies the other modules of the actual values. With this in place
> it'll be easier to have other config formats in the future: just make
> some module that understands format foo and writes/reads it to/from
> couchdb. The config process will see the changes and propagate them.
>
>
> IME it's better to keep config files away from the core of some
> application and let some external agent interpret the files and
> configure the application using an api.
Interesting.
Re: server configuration stuff
Posted by Daniel Yokomizo <da...@gmail.com>.
On Thu, Apr 10, 2008 at 5:57 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Heya,
>
> On Apr 10, 2008, at 22:22, Daniel Yokomizo wrote:
>
> >
> > A couple of thoughts.
> >
> > 1. Why not use the usual Erlang approach for code update, using the
> > loop for receiving messages and handling config updates, it seems
> > cleaner and a better fit. This way you need only a single process to
> > handle the config file format and notify the rest.
> >
>
> Can you elaborate on that for a bit considering that we're not all
> Erlang experts here :) Especially, what do you mean be "The Loop"
> and how is it conceptually different from what Damien proposes
> in his fourth and fifth paragraph? Do you mean to use the program's
> main run loop to do the job that Damien describes for a "configuration
> module"?
In Erlang the usual way to write a process is to create a
tail-recursive non-terminating function:
loop() ->
receive
Msg -> handle(Msg),
loop()
end.
To support code updates the usual trick is to create a special kind of
code update function:
loop(Handler) ->
receive
{code_update, NewHandler} -> loop(NewHandler);
Msg -> Handler(Msg),
loop(Handler)
end.
So the loop depends on a function which is the Handler, when it
receives a code_update message it starts using the NewHandler, but for
other messages it let the Handler do the job and loop again using it.
What I suggested was doing something like this:
loop(Config) ->
receive
{config_update, NewConfig} -> loop(NewConfig);
Msg -> handle(Config, Msg),
loop(Config)
end.
Then a configurator process just need to be able to send a message to
all process that use the configuration and send a config_update
message to them with the NewConfig. The configurator process is
external to the modules and can read the configuration from anywhere:
a database, a file.
> > 2. Also it would be simpler to have almost every config inside a
> > CouchDB database, so you startup using the default config and the
> > config process reads the database for the real config info and
> > notifies the other modules of the actual values. With this in place
> > it'll be easier to have other config formats in the future: just make
> > some module that understands format foo and writes/reads it to/from
> > couchdb. The config process will see the changes and propagate them.
> >
>
> Not sure if it matters where the actual data gets stored. New formats
> can be added to files as well as CouchDB documents, so one
> solution is as easy as the other. Or am I missing something?
>
>
> > IME it's better to keep config files away from the core of some
> > application and let some external agent interpret the files and
> > configure the application using an api.
> >
>
> Sorry to sound dumb again. Do you say keeping the handling
> of config files should not be in the CouchDB core? What is the
> core in this context? Would a configuration module that would
> deal with the config file considered "core" by you? Or would
> that describe that 'external agent' you mention?
The idea is to pass the config information as Erlang tuples/records to
the processes that need them, so we don't need to know which config
file format was used. Then another process (which can be plugged in)
knows how to parse a config file (or read it from a database) and
handles the parsing, builds a config tuple/record and sends it to the
configurator process, which proceeds to notify all dependent process.
%% init creates a minimal correct DefaultConfig and starts all the
core processes using DefaultConfig,
%% like the couch engine, view engine and the configurator process.
the configurator process starts
%% with a list of processes that it should notify on config updates
init() ->
DefaultConfig = {...},
CouchPid = spawn(fun() -> couch(DefaultConfig) end),
ViewPid = spawn(fun() -> view(DefaultConfig) end),
ConfigPid = spawn(fun() -> config(DefaultConfig, [CouchPid,ViewPid]) end),
ConfigPid.
%% couch represents the core CouchDB engine and knows how to handle
config_update messages
couch(Config) ->
receive
{config_update, NewConfig} -> couch(NewConfig);
Msg -> doRealCouchWork(Config, Msg),
couch(Config)
end.
%% view represents the view engine and knows how to handle
config_update messages
view(Config) ->
receive
{config_update, NewConfig} -> view(NewConfig);
Msg -> doRealViewWork(Config, Msg),
view(Config)
end.
%% config is the configurator. all it does is wait for config_update
messages to notify
%% the interested processes
config(Config, Pids) ->
receive
{config_update, NewConfig} -> notify(NewConfig, Pids),
config(NewConfig,Pids)
end.
notify(NewConfig, []) -> ok;
notify(NewConfig, [Pid|Pids]) ->
Pid ! {config_update, NewConfig},
notify(NewConfig, Pids).
Inside a plugin module we could have something like this:
init(ConfigPid) -> spawn(fun() -> loop(ConfigPid) end).
loop(ConfigPid) ->
File = read_file_blocking_until_it_changes(),
NewConfig = parse(File),
ConfigPid ! {config_update, Config},
loop(ConfigPid).
Then anyone can build it's own config file format (of course we should
have at least one standard format to encourage people to use a common
one), perhaps reading it from a database or whatever and create an
appropriate plugin module that will just do the reading and parsing.
This way we separate the issues of understanding the config file
format and where it's stored, to the notification of interested
processes to the use of the config.
> Thanks for your input!
>
> Cheers
> Jan
> --
I hope this makes things clearer.
Best regards,
Daniel Yokomizo.
Re: server configuration stuff
Posted by Jan Lehnardt <ja...@apache.org>.
Heya,
On Apr 10, 2008, at 22:22, Daniel Yokomizo wrote:
>
> A couple of thoughts.
>
> 1. Why not use the usual Erlang approach for code update, using the
> loop for receiving messages and handling config updates, it seems
> cleaner and a better fit. This way you need only a single process to
> handle the config file format and notify the rest.
Can you elaborate on that for a bit considering that we're not all
Erlang experts here :) Especially, what do you mean be "The Loop"
and how is it conceptually different from what Damien proposes
in his fourth and fifth paragraph? Do you mean to use the program's
main run loop to do the job that Damien describes for a "configuration
module"?
> 2. Also it would be simpler to have almost every config inside a
> CouchDB database, so you startup using the default config and the
> config process reads the database for the real config info and
> notifies the other modules of the actual values. With this in place
> it'll be easier to have other config formats in the future: just make
> some module that understands format foo and writes/reads it to/from
> couchdb. The config process will see the changes and propagate them.
Not sure if it matters where the actual data gets stored. New formats
can be added to files as well as CouchDB documents, so one
solution is as easy as the other. Or am I missing something?
> IME it's better to keep config files away from the core of some
> application and let some external agent interpret the files and
> configure the application using an api.
Sorry to sound dumb again. Do you say keeping the handling
of config files should not be in the CouchDB core? What is the
core in this context? Would a configuration module that would
deal with the config file considered "core" by you? Or would
that describe that 'external agent' you mention?
Thanks for your input!
Cheers
Jan
--
Re: server configuration stuff
Posted by Daniel Yokomizo <da...@gmail.com>.
On Thu, Apr 10, 2008 at 5:02 PM, Damien Katz <da...@gmail.com> wrote:
> Currently that CouchDB handles configuration stuff is to reads in it's
> configuration setting at startup time the couch.ini file, and then feeds
> those settings as startup arguments to the various child servers processes.
> This requires that to change a setting you must restart to take effect.
>
> This is fine for now, but we can do better. I'd like to enhance this by
> providing a configuration module that allows for configuration settings to
> be changed at runtime, and automatically have those changes take effect
> without requiring a server restart.
>
> The way I was thinking it would work, at startup the server configuration
> module sucks up the settings from the couch.ini, then the child processes
> are started normally, but without startup arguments. The child processes
> then query the runtime module at startup, or whenever, to get their
> configuration data.
>
> It should be possible for the core modules to subscribe notifications of
> configuration updates. In Erlang, this is typically done by the modules
> registering a callback function. So when a configuration setting is updated,
> it would get invoked with the changed settings as arguments.
>
> And when a configuration setting is changed at runtime, the module should
> write the new setting back to the couch.ini file. And it should be able to
> handle updates to settings, etc, and ideally still preserve all previous
> formatting and comments.
>
> So, some questions. What do people think of this in general? Or should we
> be using the apache conf format instead of ini? Maybe we should use json?
>
> One things I'd like to see is that configuration stuff be editable in a
> text editor. However, I might be dissuaded to start using a CouchDB database
> to store everything but the most critical startup information.
>
> Thoughts please.
A couple of thoughts.
1. Why not use the usual Erlang approach for code update, using the
loop for receiving messages and handling config updates, it seems
cleaner and a better fit. This way you need only a single process to
handle the config file format and notify the rest.
2. Also it would be simpler to have almost every config inside a
CouchDB database, so you startup using the default config and the
config process reads the database for the real config info and
notifies the other modules of the actual values. With this in place
it'll be easier to have other config formats in the future: just make
some module that understands format foo and writes/reads it to/from
couchdb. The config process will see the changes and propagate them.
IME it's better to keep config files away from the core of some
application and let some external agent interpret the files and
configure the application using an api.
Best regards,
Daniel Yokomizo.