[Engine-devel] [RFC] ovirt-engine - vdc_config default options

[Eli Mesika]

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
> Sent: Wednesday, September 12, 2012 3:57:13 PM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
> 
> 
> Hello Eli,
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
> > Sent: Wednesday, September 12, 2012 3:48:00 PM
> > Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
> > options
> > 
> > > > >>> QUESTIONS
> > > > >>>
> > > > >>> 1. Why do we store default values in database?
> > 
> > I wanted to add few important points
> > a) We have default values in DB in order to enable overriding
> > values
> > in the 0000_config.sql file only if a customer did not change the
> > default value, if a customer changed the default in some entries,
> > we
> > want to honour the customer settings
> 
> Default != value.
> Default is what should be used if not specified explicitly
> 
> Current implementation puts the default value as a value, so you
> cannot distinguish between what user enforced.
> 
> When a default is changed, because of field feedback, we should push
> this into the database instead of keeping in database only options
> that were modified by the user and fetch the default from the option
> metadata.
> 
> In another words.... there should be no 000_config.sql, the option
> table should be empty as long as the user does not modify any of the
> options.
> 

Lets assume that we are going for it, how would you upgrade from the current state to your suggested solution keeping all user current settings ?

> > b)There may be other requirements on configuration that are easier
> > to
> > manage in the database, for example, I have heard that one of the
> > suggested features regarding configuration is to keep a kind of
> > configuration history and know exactly which configuration values
> > was changed, when and by whom.
> 
> There is no conflict. You can have audit table when modifying
> options.
> Keep in mind that I discuss the option metadata.
> I believe you are discussing the option data.
You are right 

> 
> > c) The version mechanism in the config is working like this : there
> > is a 'general' version , means that this value is not version
> > dependant, or the version can be a real version like 3.1 3.2 etc ,
> > in such case the value is version dependant and an entry is
> > required
> > for each version.
> 
> Again, there is no conflict, as the default value within the metadata
> can be version specific too.
I agree , however we should consider all changes in current code + tools + upgrade since this seems a major change
> 
> Having said that, I don't understand how two different versions can
> work with the different data models and share one database and
> options.
> 
> > I agree however, that the default value in the code is redundant
> > and
> > error prone and should be removed.
> 
> From what you wrote above, I don't understand how you reached to this
> conclusion. Can you please explain?
I mean that we have now defaults in code (ConfigValues.java) and in the database they may not match.
I think as you that only one place defined the defaults, so , it should be removed from code which is less flexible if we want to change something without recompiling ...
> 
> Thanks,
> Alon.
>