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.
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.
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.
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?
Thanks,
Alon.