Re: [Engine-devel] ovirt-engine deployment method

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