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

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, engine-devel at ovirt.org
> 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" <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
> >>>
> >>> 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.