[Engine-devel] ovirt-engine deployment method

[Livnat Peer]

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