[Engine-devel] ovirt-engine deployment method

Juan Hernandez juan.hernandez at redhat.com
Wed Apr 18 10:42:41 UTC 2012


On 04/18/2012 12:18 PM, Livnat Peer wrote:
> 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.

That would be great! There are some changes that could help with that:

http://gerrit.ovirt.org/3250 - Update to Quartz 2.1
http://gerrit.ovirt.org/3251 - Update to Jackson 1.9.2
http://gerrit.ovirt.org/1390 - Remove Spring from RESTAPI
http://gerrit.ovirt.org/3002 - Update to Spring 3
http://gerrit.ovirt.org/2347 - Add methods missing in PGHack
http://gerrit.ovirt.org/2354 - Don't require activation
http://gerrit.ovirt.org/3249 - Remove dependency on JNA
http://gerrit.ovirt.org/3086 - Replace pubkey2ssh with ssh-keygen

Some of them still need work from the author ;-)

>> 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?

No, I didn't explain it correctly, sorry. It means the the "official"
ovirt-engine package included in Fedora 17 can't contain the UI (because
GWT is not in Fedora 17 yet). But the "unofficial" ovirt-engine package
can include it, and the official jboss-as package should be enough to
run the it.

>> 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.

My suggestion is that even if we decide to have two flavors of the
ovirt-engine packages (the official one without the UI and the
unofficial one with the UI) both should use the official jboss-as package.



More information about the Arch mailing list