----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Eli Mesika" <[email protected]>, [email protected] > Sent: Thursday, September 13, 2012 5:50:06 PM > Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options > > On 09/13/2012 11:36 AM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Eli Mesika" <[email protected]> > >> To: "Alon Bar-Lev" <[email protected]> > >> Cc: [email protected], "Livnat Peer" <[email protected]> > >> 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" <[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 ? > > > > Either by: > > > > 1. leaving all existing data within database... so current users > > will not enjoy updating defaults in future. I really don't like > > this solution, but it will work. > > > > 2. during upgrade, go over the values, and remove all that matches > > the metadata default. This way, future change in metadata will > > apply. > > > >> > >>>> 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 > > > > Right. I outlined all changes I collected in the initial message. > > > >>> > >>> 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 ... > > > > If we decide to use java annotations for metadata, the default will > > be in annotation. > > If we decide to use XML for metadata, the default will be in XML. > > At any case, I would like to reach to a state where the metadata is > > at one place, and not spread between code, property/xml, database. > > I may be missing something. > are you suggesting moving all the vdc_options table to an xml file? > I assume it will be placed under /etc? > > then if we update the rpm, the edited config will remain unmodified, > and > we'll get the new one as rpmsave (iirc). > then during upgrade process we'll need to merge these files? >
No... the vdc_options stays exactly as-is. I am suggesting to move the metadata to one place. metadata = option name, description, reloadable, password, default value, restriction. metadata is part of release, and not changed by user. Alon. _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
