On 12/03/15 02:50, Aline Manera wrote:
On 10/03/2015 14:39, Frédéric Bonnard wrote:
> From: Frederic Bonnard <frediz(a)linux.vnet.ibm.com>
>
> Hi,
> I'm using the patch from Julien for this one :
>
http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009840.html
> and it wasn't taking the option into account, here is some changes
> that worked for me.
>
> Also, I think that the goal of disabling nginx in this patch is not to
> use kimchi
> directly, but to use another instance of nginx as I did or apache as
> Julien does.
I have some points on it:
1) If we allow user to disable nginx proxy we need to make sure kimchi
server will continue working as expected whatever is the user reason to
do that.
As long as someone uses a proxy (or some other way to make it accessible
like using it on a desktop, or SSH port forwards) Kimchi just works,
there's nothing special about nginx.
WRT that the X-* options are sensible, but cherrypy shouldn't be setting
HSTS since it can't know if it'll be proxied using TLS. Obviously for
the websockets based console to work it'll need to be via TLS.
I've updated my patch to include them and will resend it, I could also
look at setting them on the Kimchi side as well.
2) If the idea is allow using other proxy instead of nginx, what are
the
options? How would user use them? How does Kimchi will deal with them?
Royce also comments on that:
http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009655.html
Remember, Kimchi is focused on entry level users which means it must be
easy and simple since installation/configuration time and it affects all
changes we do.
I don't think that's a real problem, the users likely to want to run
their own proxy are those who would (predominantly at least) already
know what they want to use, and how to configure it. Novice users will
simply keep the default setting and continue using nginx unchanged.
The inclusion of an apache2 configuration snippet is two-fold, first,
it's the most common web server still and thus the most likely to be
wanted as a proxy; second, being the most common it's common for other
web servers to include a translation of apache terms in their
documentation, or documents that others write.