Re: [Engine-devel] Reloadable Configuration - Wiki Page

1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk. 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon. 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect. 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for. These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration. 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value. ----- Original Message -----