From: "Barak Azulay" <bazulay(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, May 8, 2013 10:02:29 PM
Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache proxy
(
https://bugzilla.redhat.com/905754)
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Barak Azulay" <bazulay(a)redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>,
"engine-devel"
> <engine-devel(a)ovirt.org>, "users" <users(a)ovirt.org>
> Sent: Wednesday, May 8, 2013 5:20:51 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> Apache proxy
> (
https://bugzilla.redhat.com/905754)
>
>
>
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay(a)redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>,
"engine-devel"
> > <engine-devel(a)ovirt.org>, "users" <users(a)ovirt.org>
> > Sent: Wednesday, May 8, 2013 4:00:34 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache proxy
> > (
https://bugzilla.redhat.com/905754)
> >
> >
> >
> > ----- Original Message -----
> > > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"users" <users(a)ovirt.org>
> > > Sent: Wednesday, May 8, 2013 3:51:03 PM
> > > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > > use
> > > Apache proxy
> > > (
https://bugzilla.redhat.com/905754)
> > >
> > > Hello,
> > > if I've understood correctly then:
> > > - there is no reason for checking if user altered http configuration
> > > - proxy doesn't depend on any other related http configuration we do
> > > and
> > > does not alter any other configuration file, so we can do it without
> > > asking anything
> > > - if ipa is installed, engine-setup should issue a warning about it and
> > > default to No for 'set ovirt-engine as default page' and
'configure
> > > apache ssl'
> >
> >
> > AFAIU and I don't think it was changed, there is a conflict between IPA
> > and
> > mod_ssl (they did it ugly ... not in rpm level... that was the status a
> > year
> > ago)
> >
> > SO it will not work, as long we do not move to mod_nss.
> >
> > In addition there wad an issue with mod_proxy and using 2 different SSL
> > certificates (IPA & RHEV) on the same apache server.
> >
> >
> > please make sure all the above are solved.
>
> I just do not understand why we treat IPA in special way... it is as if we
> need to have knowledge of very application out there that hacks the apache.
>
> Playing nice with mod_nss and not force mod_ssl or actually any is a
> positive
> move.
The reason is that in 3.0 we supported IPA (and PMs even recommended to
install it on the same host as RHEVM so save HW)
So if someone continues with that deployment we should not break it.
Having said that - we need to handle any installation on any supported RHEL
version,
on those server one might have apache with other application, and you have
said we should not assume we own the host.
Right.
First, we need to support any installation not just rhel.
Second, we can support only other well behaved products.
Until recently we were not well behaved... well we still not fully because we do not have
our own configurable URI namespace.
We cannot control which applications are installed on the same host, however we can:
1. postgresql: support skipping the automatic provisioning [supported in the otopi setup]
2. apache: do not enforce specific apache SSL implementation [to be done].
3. apache: support skipping the automatic SSL configuration [supported].
4. apache: support skipping the root redirect to ovirt application [supported in otopi
setup]
5. apache: move application to own name space, example /ovirt-engine [to be done, I will
be happy if you can help pushing this]
6. firewall: support skipping configuration [supported]
7. packaging: remove the versionlock usage.
8. packaging: support proper upgrade path, compatible with packaging best practices.
9. files: rename all utilities and public artifacts from engine-* to ovirt-engine-*
[more?]
If we do the above we are acting as well behaved application, and can co-exist with other
well behaved applications.
Barak
>
> Thanks,
> Alon
>
> >
> >
> > Thanks
> > Barak
> > >
> > > I think I've enough info.
> > > Thanks.
> > >
> > >
> > > Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Barak Azulay" <bazulay(a)redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > >> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>,
"engine-devel"
> > > >> <engine-devel(a)ovirt.org>, "users"
<users(a)ovirt.org>
> > > >> Sent: Monday, May 6, 2013 10:42:02 PM
> > > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation
> > > >> must
> > > >> use
> > > >> Apache proxy
> > > >> (
https://bugzilla.redhat.com/905754)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl(a)redhat.com>
wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> I don't understand why you start discussion from start...
there
> > > >>> were
> > > >>> some
> > > >>> additional facts.
> > > >>>
> > > >>> So first answer:
> > > >>> No we cannot assume we own the machine nor own the apache,
nor own
> > > >>> the
> > > >>> postgresql. These assumptions made in the past were plain
wrong and
> > > >>> cause
> > > >>> more harm than good, and eventually saved no resources nor
efforts.
> > > >>>
> > > >>> At master we altered the ajp proxy configuration to be less
> > > >>> intrusive[1][2].
> > > >>>
> > > >>> We split the http configuration into three:
> > > >>> 1. Install ajp proxy per our URIs[1].
> > > >>> 2. Optionally set root redirection from / to /ovirt-engine
> > > >>> 3. Optionally configure mod_ssl with our certificate.
> > > >> I don't know if this was already brought up,
> > > >>
> > > >> There is a conflict between our configuration and IPA's
> > > >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this
creates
> > > >> a
> > > >> conflict.
> > > >>
> > > >> We can try move to mod_nss on upgrade and solve all issues
> > > >>
> > > >> Barak
> > > > The fact that ovirt-engine depends on mod_ssl is a mistake... well,
> > > > at
> > > > least I think so.
> > > > The product should not care how ssl is provided as long as it is
> > > > provided.
> > > >
> > > > Personally, I think that product should not attempt to configure ssl
> > > > at
> > > > all, but provide the instructions of how to do so... But never the
> > > > less,
> > > > let's try to keep this to avoid argument.
> > > >
> > > > In case IPA is installed (and I really don't understand why
should we
> > > > care
> > > > about IPA specifically, well, I actually do... as IPA makes the same
> > > > faulty assumptions of 'owning' resources), the admin should
just
> > > > avoid
> > > > selecting the 'set ovirt-engine as default page' and
'configure
> > > > apache
> > > > ssl', user should access ovirt-engine using:
> > > >
http://host/ovirt-engine
> > > >
> > > > It should work as long as there are no URI conflicts between
products
> > > > as
> > > > I
> > > > listed in previous message.
> > > >
> > > > Regards,
> > > > Alon
> > > >
> > > >>> The mandatory apache configuration[1] does not alter any
> > > >>> configuration
> > > >>> file, hence the chance of conflict is the chance of conflict
> > > >>> between
> > > >>> ovirt-engine URIs and other product URIs.
> > > >>>
> > > >>> ovirt-engine URIs:
> > > >>> ---
> > > >>> /UserPortal
> > > >>> /OvirtEngineWeb
> > > >>> /webadmin
> > > >>> /docs
> > > >>> /spice
> > > >>> /ca.crt
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ovirt-engine-style.css
> > > >>> /console.vv
> > > >>> /api
> > > >>> /ovirt-engine
> > > >>> ---
> > > >>>
> > > >>> As we have done this without cooperation of developers we
kept URIs
> > > >>> as-is.
> > > >>>
> > > >>> URIs that cannot be changed until next major:
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ca.crt
> > > >>> /api [I guess, although we can provide migration path
alternative]
> > > >>>
> > > >>> All the other can be moved into /ovirt-engine with
cooperation of
> > > >>> developers, especially UI and Virt developers, it should be
easy to
> > > >>> do
> > > >>> this, and reduce the chance of conflict.
> > > >>>
> > > >>> Regards,
> > > >>> Alon Bar-Lev.
> > > >>>
> > > >>> [1]
http://gerrit.ovirt.org/#/c/13318/
> > > >>> [2]
http://gerrit.ovirt.org/#/c/14304/
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Sandro Bonazzola"
<sbonazzo(a)redhat.com>
> > > >>>> To: "engine-devel"
<engine-devel(a)ovirt.org>
> > > >>>> Cc: "users" <users(a)ovirt.org>
> > > >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> > > >>>> Subject: [Engine-devel] 3.3 scratch or upgraded
installation must
> > > >>>> use
> > > >>>> Apache proxy
> > > >>>> (
https://bugzilla.redhat.com/905754)
> > > >>>>
> > > >>>> Hi,
> > > >>>> I'm working on
https://bugzilla.redhat.com/905754,
trying to have
> > > >>>> Apache
> > > >>>> proxy in all 3.3 installations.
> > > >>>>
> > > >>>> I'm looking in the code and I've found a point
where I'm in doubt
> > > >>>> about
> > > >>>> how to handle the case.
> > > >>>> The current engine-setup implementation perform some
checks that
> > > >>>> change
> > > >>>> the behavior of the installer documented as:
> > > >>>>
> > > >>>> 1. Check whether the relevant httpd configuration files
were
> > > >>>> changed,
> > > >>>> as
> > > >>>> it's an indication for the setup that the httpd
application is
> > > >>>> being
> > > >>>> actively used, Therefore we may need to ask (dynamic
change) the
> > > >>>> user
> > > >>>> whether to override this configuration.
> > > >>>>
> > > >>>> 2. Check if IPA is installed and drop port 80/443
support. What
> > > >>>> the
> > > >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default
to False
> > > >>>> in
> > > >>>> both cases and just for case 2 call also
> > > >>>> setHttpPortsToNonProxyDefault.
> > > >>>>
> > > >>>>
> > > >>>> About 1, if we can consider Apache "owned" by
the engine we can
> > > >>>> drop
> > > >>>> any
> > > >>>> question to the user, else I think we need to ask what to
do or
> > > >>>> abort
> > > >>>> the setup considering the configuration as unsupported.
> > > >>>>
> > > >>>> About 2, it seems that the best solution for that is to
abort the
> > > >>>> setup
> > > >>>> if IPA is found on the same system where
> > > >>>> we're installing the engine.
> > > >>>> As far I've understood having IPA and engine on the
same host is
> > > >>>> not
> > > >>>> a
> > > >>>> supported configuration.
> > > >>>>
> > > >>>>
> > > >>>> What do you think about this?
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Sandro Bonazzola
> > > >>>> Better technology. Faster innovation. Powered by
community
> > > >>>> collaboration.
> > > >>>> See how it works at
redhat.com
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> 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
> > > >>>
> > > >>>
> > >
> > >
> > > --
> > > Sandro Bonazzola
> > > Better technology. Faster innovation. Powered by community
> > > collaboration.
> > > See how it works at
redhat.com
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
>