[Engine-devel] Reloadable Configuration - Wiki Page

Muli Salem msalem at redhat.com
Thu Mar 29 08:05:38 UTC 2012


Thanks for the comments, I updated the wiki page accordingly:
http://www.ovirt.org/wiki/Features/ReloadableConfiguration

1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues.
2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, March 27, 2012 1:20:01 PM
> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
> 
> On 03/27/2012 08:18 AM, Itamar Heim wrote:
> > On 03/26/2012 09:53 PM, 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.
> >> 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
> 
> Agreed. Current code in engine-core uses a generic method to get the
> value, and uses @TypeConverterAttribute annotation to give indication
> to
> which type the data should be "cast" to.
> See DbConfigUtils.parseValue(String value, String name,
> java.lang.Class<?> fieldType)
> 
> >> 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.
> > 
> > a different take on this - why not just annotate the enums with
> > this
> > information?
> 
> +1 On annotation idea - although this introduces "information on
> behavior" to code, and any change will require re-compiling, I don't
> see
> why anyone would like to change the behavior.
> 
> > also, not sure configuration should be reloaded per change
> > automatically. maybe user wants it to happen on next restart, maybe
> > some
> > changes must happen together.
> > i.e., I'd expect a specific 'reconfigure' call to make it happen
> > rather
> > than poll for it.
> > 
> >> 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.
> Muli - are you sure about Quartz? Have you checked it out?
> 
> >>
> >> ----- Original Message -----
> >>> From: "Muli Salem"<msalem at redhat.com>
> >>> To: engine-devel at 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 at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



More information about the Devel mailing list