----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Eli Mesika" <[email protected]> > Cc: [email protected], "Livnat Peer" <[email protected]> > 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" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]> > > Cc: [email protected], "Livnat Peer" <[email protected]> > > 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. > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
