11:39 a.m.
Hi Guys,
We recently merged at a patch (http://gerrit.ovirt.org/#/c/13181/) that allows
for limited branding support of oVirt user portal and web admin. We also moved
the styles needed to support this branding out of the application and into its
own module. The styles can now be found in ovirt-
engine/packaging/branding/ovirt.brand.
In this directory you will find the following files:
- branding.properties. This file controls the branding theme.
- ovirt_messages.properties. A standard java resource bundle properties file
containing the messages that can be changed.
- A bunch of .css files that contain the classes that can be altered.
I have created a wiki page with some information and pictures of what parts of
the interface can be changed at this point in time. It is located here:
http://www.ovirt.org/Feature/Branding
There is also more information in README.branding that got introduced with
this patch.
Alexander
ps.
If your user interface looks messed up (missing borders and things of that
nature) the engine cannot find the default branding. This means you are not
using the make commands recently introduced. We highly recommend you use this
to have a complete environment. If you are unwilling or unable to use that you
can make a symlink in /etc/ovirt-engine/branding/00-ovirt.brand to ovirt-
engine/packaging/branding/ovirt.brand
3:46 a.m.
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?
Thx,
Laszlo
----- Original Message -----
From: "Alexander Wels" <awels(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Tuesday, June 11, 2013 6:39:20 PM
Subject: [Engine-devel] Introducing limited branding support.
Hi Guys,
We recently merged at a patch (http://gerrit.ovirt.org/#/c/13181/) that
allows
for limited branding support of oVirt user portal and web admin. We also
moved
the styles needed to support this branding out of the application and into
its
own module. The styles can now be found in ovirt-
engine/packaging/branding/ovirt.brand.
In this directory you will find the following files:
- branding.properties. This file controls the branding theme.
- ovirt_messages.properties. A standard java resource bundle properties file
containing the messages that can be changed.
- A bunch of .css files that contain the classes that can be altered.
I have created a wiki page with some information and pictures of what parts
of
the interface can be changed at this point in time. It is located here:
http://www.ovirt.org/Feature/Branding
There is also more information in README.branding that got introduced with
this patch.
Alexander
ps.
If your user interface looks messed up (missing borders and things of that
nature) the engine cannot find the default branding. This means you are not
using the make commands recently introduced. We highly recommend you use this
to have a complete environment. If you are unwilling or unable to use that
you
can make a symlink in /etc/ovirt-engine/branding/00-ovirt.brand to ovirt-
engine/packaging/branding/ovirt.brand
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:54 a.m.
----- 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?
Regards,
Alon Bar-Lev.
4:32 a.m.
----- 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.
Regards,
Alon Bar-Lev.
5:23 a.m.
New subject: [Engine-devel] Database configuration vs File based configuration (Was: Introducing limited branding support)
----- 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.
5:59 a.m.
On 06/11/2013 10:09 PM, Alexander Wels wrote:
Hi Guys,
We recently merged at a patch (http://gerrit.ovirt.org/#/c/13181/) that allows
for limited branding support of oVirt user portal and web admin. We also moved
the styles needed to support this branding out of the application and into its
own module. The styles can now be found in ovirt-
engine/packaging/branding/ovirt.brand.
In this directory you will find the following files:
- branding.properties. This file controls the branding theme.
- ovirt_messages.properties. A standard java resource bundle properties file
containing the messages that can be changed.
- A bunch of .css files that contain the classes that can be altered.
I have created a wiki page with some information and pictures of what parts of
the interface can be changed at this point in time. It is located here:
http://www.ovirt.org/Feature/Branding
There is also more information in README.branding that got introduced with
this patch.
Alexander
ps.
If your user interface looks messed up (missing borders and things of that
nature) the engine cannot find the default branding. This means you are not
using the make commands recently introduced. We highly recommend you use this
to have a complete environment. If you are unwilling or unable to use that you
can make a symlink in /etc/ovirt-engine/branding/00-ovirt.brand to ovirt-
engine/packaging/branding/ovirt.brand
If creating a symlink, make sure it matches
the ENGINE_ETC property
that's loaded.
So, for symlink /etc/ovirt-engine/branding/00-ovirt.brand , the
ENGINE_ETC should be pointing to /etc/ovirt-engine.
I ran into issues, so thought I would share.
thanks
sahina
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:54 a.m.
----- Original Message -----
From: "Sahina Bose" <sabose(a)redhat.com>
To: awels(a)redhat.com
Cc: engine-devel(a)ovirt.org
Sent: Thursday, June 13, 2013 1:59:29 PM
Subject: Re: [Engine-devel] Introducing limited branding support.
On 06/11/2013 10:09 PM, Alexander Wels wrote:
> Hi Guys,
>
> We recently merged at a patch (http://gerrit.ovirt.org/#/c/13181/) that
> allows
> for limited branding support of oVirt user portal and web admin. We also
> moved
> the styles needed to support this branding out of the application and into
> its
> own module. The styles can now be found in ovirt-
> engine/packaging/branding/ovirt.brand.
>
> In this directory you will find the following files:
> - branding.properties. This file controls the branding theme.
> - ovirt_messages.properties. A standard java resource bundle properties
> file
> containing the messages that can be changed.
> - A bunch of .css files that contain the classes that can be altered.
>
> I have created a wiki page with some information and pictures of what parts
> of
> the interface can be changed at this point in time. It is located here:
> http://www.ovirt.org/Feature/Branding
>
> There is also more information in README.branding that got introduced with
> this patch.
>
> Alexander
>
> ps.
> If your user interface looks messed up (missing borders and things of that
> nature) the engine cannot find the default branding. This means you are not
> using the make commands recently introduced. We highly recommend you use
> this
> to have a complete environment. If you are unwilling or unable to use that
> you
> can make a symlink in /etc/ovirt-engine/branding/00-ovirt.brand to ovirt-
> engine/packaging/branding/ovirt.brand
If creating a symlink, make sure it matches the ENGINE_ETC property
that's loaded.
So, for symlink /etc/ovirt-engine/branding/00-ovirt.brand , the
ENGINE_ETC should be pointing to /etc/ovirt-engine.
I ran into issues, so thought I would share.
Please migrate to the new supported development environment[1], it installs everything as
it should, you should not set these variables manually.
Regards,
Alon Bar-Lev.
[1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.develop...
thanks
sahina
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:31 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Sahina Bose" <sabose(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, June 13, 2013 2:54:29 PM
Subject: Re: [Engine-devel] Introducing limited branding support.
----- Original Message -----
> From: "Sahina Bose" <sabose(a)redhat.com>
> To: awels(a)redhat.com
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, June 13, 2013 1:59:29 PM
> Subject: Re: [Engine-devel] Introducing limited branding support.
>
>
> On 06/11/2013 10:09 PM, Alexander Wels wrote:
> > Hi Guys,
> >
> > We recently merged at a patch (http://gerrit.ovirt.org/#/c/13181/) that
> > allows
> > for limited branding support of oVirt user portal and web admin. We also
> > moved
> > the styles needed to support this branding out of the application and
> > into
> > its
> > own module. The styles can now be found in ovirt-
> > engine/packaging/branding/ovirt.brand.
> >
> > In this directory you will find the following files:
> > - branding.properties. This file controls the branding theme.
> > - ovirt_messages.properties. A standard java resource bundle properties
> > file
> > containing the messages that can be changed.
> > - A bunch of .css files that contain the classes that can be altered.
> >
> > I have created a wiki page with some information and pictures of what
> > parts
> > of
> > the interface can be changed at this point in time. It is located here:
> > http://www.ovirt.org/Feature/Branding
> >
> > There is also more information in README.branding that got introduced
> > with
> > this patch.
> >
> > Alexander
> >
> > ps.
> > If your user interface looks messed up (missing borders and things of
> > that
> > nature) the engine cannot find the default branding. This means you are
> > not
> > using the make commands recently introduced. We highly recommend you use
> > this
> > to have a complete environment. If you are unwilling or unable to use
> > that
> > you
> > can make a symlink in /etc/ovirt-engine/branding/00-ovirt.brand to ovirt-
> > engine/packaging/branding/ovirt.brand
> If creating a symlink, make sure it matches the ENGINE_ETC property
> that's loaded.
> So, for symlink /etc/ovirt-engine/branding/00-ovirt.brand , the
> ENGINE_ETC should be pointing to /etc/ovirt-engine.
>
> I ran into issues, so thought I would share.
Please migrate to the new supported development environment[1], it installs
everything as it should, you should not set these variables manually.
There is a good wiki from Alon as well that I think is more easy to follow
http://www.ovirt.org/OVirt_Engine_Development_Environment
Regards,
Alon Bar-Lev.
[1]
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.develop...
>
> thanks
> sahina
>
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3960
days inactive
3965
days old
7 comments
5 participants
participants (5)
-
Alexander Wels -
Alon Bar-Lev -
Eli Mesika -
Laszlo Hornyak -
Sahina Bose