1:23 p.m.
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: awels(a)redhat.com, engine-devel(a)ovirt.org
Sent: Wednesday, June 12, 2013 12:32:40 PM
Subject: Re: [Engine-devel] Introducing limited branding support.
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: awels(a)redhat.com, engine-devel(a)ovirt.org
> Sent: Wednesday, June 12, 2013 10:54:45 AM
> Subject: Re: [Engine-devel] Introducing limited branding support.
>
>
>
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > To: awels(a)redhat.com
> > Cc: engine-devel(a)ovirt.org
> > Sent: Wednesday, June 12, 2013 11:46:23 AM
> > Subject: Re: [Engine-devel] Introducing limited branding support.
> >
> > Hi,
> >
> > A related question to the designers:
> > How do you decide if a new configuration goes to the database config, an
> > existing or a new config file? Is there a concept for this?
>
> Hello Laszlo,
>
> I do not fully understand the question in this context.
>
> Just to make sure I understand, do you suggest that css, images and
> messages
> will be stored in database?
Oh no, I wasn't thinking of blobs local FS is just OK. I mean some
configuration parameters are stored in /etc/somewhere, some in
/etc/somewhereelse and some in the database, and I'd just like to understand
what is the concept.
There is no single concept... however I can present you one...
I hope it will answer your question.
1. Packaging considerations
Why: During package installation and upgrade the database cannot be accessed.
Example: Plugin installation can drop a file but not modify database.
2. Default values should not be stored at database
Why: Product upgrade may update default, if stored in database the upgrade process must
also access the database to update defaults and add new defaults.
Solution: Application should query database, if missing revert to default within file, if
missing revert to default within application.
Current state: We do store defaults within database, this should be fixed.
3. Options that are not controlled by application (and owner) but controlled by system and
sysadmin should not be stored in database:
Example: File locations, no sense to keep these in database if application does not
control the location, especially if may be modified between installations and
distributions.
Example: Packaging, product version.
Example: Host name, should actually be acquired from system unless overridden.
Example: Service parameters, in this case sysadmin expects these to be at their standard
locations.
Current state: We still store file locations within database, this should be fixed.
4. Database connection information
Why: Egg and chicken.
5. Local protected data
Why: Database is exposed to anyone, even if we encrypt a field we need to access the local
key, which resides outside of the database. A simple solution for local resources is to
use the operating system ACL.
Example: The password of the engine keystore which is local resource.
6. Values that are used by other technologies used for maintenance
Why: If product is using multiple technologies to handle a resource (shell scripts, python
scripts and java), it is easier to have it in configuration than in database. Especially
if these required during setup or maintenance, as database may be unavailable. These are
usually local resources already covered by the above items.
Example: The location and password of the engine key which is used by log collector,
database upgrade, setup, upgrade.
Regards,
Alon Bar-Lev.