5:33 a.m.
On 26/03/12 21:53, Saggi Mizrahi wrote:
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.
I agree, I think this should not be persist in the data base, a simple
annotation can do the work of marking a property as re-loadable or not.
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.
+1,
I think reloading configuration values should be only on demand.
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.
A nice to have IMO, we don't have it today and all values change require
reboot.
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.
I think it is used for validations but I don't really remember I can
take a look.
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.
What do you mean by committed to it?
the DB schema is not part of the API, we change it as we go.
same as having a property file and changing the key in it (only the
upgrade process is much easier when you are using data base).
Having a regular config file might be simpler for users to edit and
for you to maintain.
not sure what you mean by 'regular', in the enterprise management world
storing configuration in data base is a regular thing to do.
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.
And the tools you have for data bases which make the maintaining process
much easier.
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.
The definition of what is reloadable is based on how much work it takes
to change it from a static config to a reloadable config.
Of course you can reload the time configuration used by a quartz service
it requires to cancel the job and reschedule it with the new
configuration value. it is just not as easy as the other changes that's
why this is the 4th phase of this feature.
----- Original Message -----
> From: "Muli Salem" <msalem(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Monday, March 26, 2012 1:10:10 PM
> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
>
> Hi All,
>
> Below please find a wiki page regarding the design of the Reloadable
> Configuration feature.
> You are more than welcome to review and comment.
>
> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>
> Thanks,
> Muli
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel