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

[Alon Bar-Lev]

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: engine-devel at 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 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"

Right, will be implemented.

> >>>>
> >>>> 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)

Metadata is not updated. it is delivered with release.
It comes as resource as any other resource we have within application.

Adding a new option to metadata implies that this option was not available at previous release, so after upgrade if application tries to access this option it will not find it in database and then retrieve the default from the metadata.

If a description is updated within metadata, it will be available immediately after upgrade, as description is taken directly from metadata.

I may miss something from your question...

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