2:46 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)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(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)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.