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 _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
