----- Original Message ----- > From: "Laszlo Hornyak" <lhorn...@redhat.com> > To: "Alon Bar-Lev" <alo...@redhat.com> > Cc: aw...@redhat.com, engine-devel@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" <alo...@redhat.com> > > To: "Laszlo Hornyak" <lhorn...@redhat.com> > > Cc: aw...@redhat.com, engine-devel@ovirt.org > > Sent: Wednesday, June 12, 2013 10:54:45 AM > > Subject: Re: [Engine-devel] Introducing limited branding support. > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" <lhorn...@redhat.com> > > > To: aw...@redhat.com > > > Cc: engine-devel@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. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
