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

From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; To: engine-devel(a)ovirt.org Sent: Thursday, September 13, 2012 5:57:48 PM Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options On 09/13/2012 05:50 PM, Itamar Heim wrote: > On 09/13/2012 11:36 AM, Alon Bar-Lev wrote: >> >> >> ----- 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: 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 I agree here, maybe we should consider a future possibility of "reset to default value"

>>>> >>>> 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. Not sure I fully understand how upgrade of configuration will look? I'm talking about update of existing data (+meta data - for example, change of existing description) vs introducing of new data (+ metadata)

>>>> >>> >>> 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? > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel