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

[Yair Zaslavsky]

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 at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
>>> 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 at redhat.com>
>>>> To: "Eli Mesika" <emesika at redhat.com>
>>>> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
>>>> 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 at redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> Cc: engine-devel at ovirt.org, "Livnat Peer" <lpeer at 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
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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel