5:19 p.m.
Discussing offline versus online compression in #rdo.
What do we do now? Its ugly. The compression is performed at RPM
build time. THis is ugly, because the Javascript files it is
compressing come from other RPMS. So, if you update the RPM that has
newer javascript, the RPM will not see the change, and show the old code.
What we want is to specify that the compression script runs before
Horizon starts. While we know we need to optimize the script to keep
restart times down, that is an issue that needs to be solved upstream as
well. Lets assume for the moment that we will always run it.
The compression needs to be done in the system, but should not be done
by the HTTPD daemon itself; Static files should be owned by a user other
than the one that runs HTTPD.
The right answer seems to be systemd, since we use systemd to restart
httpd. We should be able to indicate that it needs to run the
compression script. We don't want to create a separate service for
openstack-dashboard, though; the service is HTTPD.
Steve Gallagher was kind enough to walk me through the basics. He
pointed me to what reviewboard (another mod_wsgi App) does. It installs
a file under
/usr/lib/systemd/system/httpd.service.d
named reviewboard-sites.conf. It looks like this:
|[Service]
ExecStartPre=/usr/bin/rb-site upgrade --all-sites
[Unit]
After=postgresql.service mariadb.service mysql.service memcached.service|
(visible at
http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/reviewboard-sites...)
so for horizon:
|ExecStartPre=python ${horizon_path}/manage.py compress --force-if-not-fresh|
I think this should be the pattern for all of the HTTPD hosted
services. We should do this with Keystone next.
1:48 a.m.
Can you compress at RPM install time?
Y.
From: rdo-list-bounces(a)redhat.com [mailto:rdo-list-bounces@redhat.com] On Behalf Of Adam
Young
Sent: Tuesday, April 14, 2015 1:19 AM
To: rdo-list(a)redhat.com
Subject: [Rdo-list] Systemd extension for HTTPD hosted applications
Discussing offline versus online compression in #rdo.
What do we do now? Its ugly. The compression is performed at RPM build time. THis is
ugly, because the Javascript files it is compressing come from other RPMS. So, if you
update the RPM that has newer javascript, the RPM will not see the change, and show the
old code.
What we want is to specify that the compression script runs before Horizon starts. While
we know we need to optimize the script to keep restart times down, that is an issue that
needs to be solved upstream as well. Lets assume for the moment that we will always run
it.
The compression needs to be done in the system, but should not be done by the HTTPD daemon
itself; Static files should be owned by a user other than the one that runs HTTPD.
The right answer seems to be systemd, since we use systemd to restart httpd. We should be
able to indicate that it needs to run the compression script. We don't want to create
a separate service for openstack-dashboard, though; the service is HTTPD.
Steve Gallagher was kind enough to walk me through the basics. He pointed me to what
reviewboard (another mod_wsgi App) does. It installs a file under
/usr/lib/systemd/system/httpd.service.d
named reviewboard-sites.conf. It looks like this:
[Service]
ExecStartPre=/usr/bin/rb-site upgrade --all-sites
[Unit]
After=postgresql.service mariadb.service mysql.service memcached.service
(visible at
http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/reviewboard-sites...)
so for horizon:
ExecStartPre=python ${horizon_path}/manage.py compress --force-if-not-fresh
I think this should be the pattern for all of the HTTPD hosted services. We should do
this with Keystone next.
8:24 a.m.
On 14 Apr 2015, at 03:15, Matthias Runge <mrunge(a)redhat.com>
wrote:
On 14/04/15 08:48, Kaul, Yaniv wrote:
> Can you compress at RPM install time?
>
> Y.
>
Yes, you can. But that won't take updated dependencies into account.
Horizon uses a tonne of javascript and css stuff; if that gets updated, that should
result in refreshed compressed files.
In my understanding, the most sane option is to compress it when the RPM is built — the
very same thing as if you were building a binary executable. Compiling a binary on RPM
install would not make sense, and neither it would be to compile it every single time it’s
executed, right?
Compressed JS/CSS files are ugly.. but so they are binary files, and we have to live them
too. As I see it, this is NOTABUG :)
Best,
Alvaro
10:18 a.m.
On 04/14/2015 09:24 AM, Alvaro Lopez Ortega wrote:
> On 14 Apr 2015, at 03:15, Matthias Runge
<mrunge(a)redhat.com> wrote:
> On 14/04/15 08:48, Kaul, Yaniv wrote:
>> Can you compress at RPM install time?
>>
>> Y.
>>
> Yes, you can. But that won't take updated dependencies into account.
> Horizon uses a tonne of javascript and css stuff; if that gets updated, that should
result in refreshed compressed files.
In my understanding, the most sane option is to compress it when the RPM is built — the
very same thing as if you were building a binary executable. Compiling a binary on RPM
install would not make sense, and neither it would be to compile it every single time it’s
executed, right?
Compressed JS/CSS files are ugly.. but so they are binary files, and we have to live them
too. As I see it, this is NOTABUG :)
The comparable other would be linking, not compiling.
We will find ourselves in a case where the compression has used a
version of a Javascript file with a bug in it, the bug has been fixed in
the RPM, but Horizon will still need to live with it. The right thing
to do is make it possible to recompress on the remote machine.
We can certainly do this at RPM install time, and make it a manual
process to recompress. That will lead to support requests, but at least
it is solvable.
So, I think the realistic approach is to compress when we install the
RPM, provide docs for how to manually recompress, and work towards
making this sane in to do in systemd. The first two are packaging tasks
and should be straight forward. The third we should work on for the
Liberty release.
Best,
Alvaro
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
3299
days inactive
3300
days old
4 comments
4 participants
participants (4)
-
Adam Young -
Alvaro Lopez Ortega -
Kaul, Yaniv -
Matthias Runge