1:18 p.m.
On 18/04/12 12:42, Juan Hernandez wrote:
On 04/18/2012 11:17 AM, Livnat Peer wrote:
> On 17/04/12 16:20, Ofer Schreiber wrote:
>> As decided earlier, oVirt next release (3.1) is targeted for Fedora 17.
>> Since the engine uses JBoss, we have two deployment options:
>> 1. Continue working with ovirt-engine-jbossas package
>> PROS: Single rpm. known upgrade method.
>> CONS: Maintaining un-natural zip based rpm. No official support. Can't be
pushed into Fedora.
>>
>> 2. Move to JBoss F17 official packages:
>> PROS: Fully supported F17 rpms (including bug fixes, security fixes, etc).
"The right thing to do".
>> CONS: Upgrade from first release (relaying on old jboss) will be almost
impossible, Some open issues (will it work just as as normal service? or will we need to
code a new one?), Might cause a delay to Feature Freeze.
>>
>> Thought? Comments?
>
> I think it is too soon to move to the Jboss packaged for Fedora17.
> It was just packaged and I am not aware of any developer actually
> working with oVirt on the Jboss packaged for Fedora (except for one).
> I expect to at least have the developers working with this Jboss for a
> while before releasing on it.
>
> Can anyone provide info on how different is Jboss for Fedora than the
> current upstream Jboss we use?
The main difference is that the version being packaged for Fedora 17
contains a subset of the modules: those needed for the web profile
except Hibernate. In addition the main configuration file is also
different: standalone-web.xml instead of standalone.xml. Additional
modules will be added as needed. Eventually all the modules available
upstream will be available in the Fedora packaging, but that will take time.
With the currently available packages ovirt-engine 3.0 can run correctly
(only backend and restapi, not the frontend). It needs changes, but it
can run, and most of those changes are not really related to the
differences in jboss-as, but to the differences in other packages like
quartz, resteasy, jackson, spring, etc. I believe that the same applies
to 3.1.
Maybe for 3.1 we should change upstream to use the same Jar versions as
we use in the Fedora deployment. That would take us one step closer to a
parity version.
In order for a ovirt developer to use the Fedora packaging it will need
a lot of additional modules and tools, specially for the frontend, that
are not currently available in Fedora 17. If we wait for that then we
should re-target for Fedora 18.
Is that mean that our next release, if we use Jboss packaged in Fedora,
will not include UI?
My opinion is that we should use the Fedora 17 packages for
deployment,
independently of what we use for development. It is challenging, but I
believe is "the right thing to do".
Juan, thank you for the detailed answer.
I suggest that for the upcoming release we'll do both, have 2 release
flavors, one RPM's like we released for 3.0 (with Jboss included) and
the other one tailored for Fedora.
Thanks, Livnat