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

From: "Eli Mesika" <emesika(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com&gt; Sent: Thursday, September 13, 2012 10:46:41 AM Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options ----- Original Message ----- > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > To: "Eli Mesika" <emesika(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com&gt; > 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&gt; > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com&gt; > > 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 ...