[Engine-devel] ovirt-engine deployment method

[Ofer Schreiber]

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

Having two release flavors for the next version? sounds wrong to me.
We will have to code & test two separate environments. this will require us to duplicate spec file, setup code and upgrade.


> 
> 
> Thanks, Livnat
> 
>