[Engine-devel] ovirt-engine deployment method
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? Share them with us! --- Ofer Schreiber oVirt Release Manager
On Tue, 2012-04-17 at 09:20 -0400, 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.
Quick thoughts -- this will come up for every release until we decide on #2. The con for #2 will always be there until we finally switch over. I think it's less impact to have a more manual upgrade between release 1 and 2 than between later releases. As long as we can provide at least a manual upgrade process with well defined steps so that the early adopters don't have to re-create their environments, I think we should go with #2. Mike
Thought? Comments? Share them with us! --- Ofer Schreiber oVirt Release Manager _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
On 04/17/2012 04:31 PM, Mike Burns wrote:
On Tue, 2012-04-17 at 09:20 -0400, 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.
Quick thoughts -- this will come up for every release until we decide on #2. The con for #2 will always be there until we finally switch over. I think it's less impact to have a more manual upgrade between release 1 and 2 than between later releases.
As long as we can provide at least a manual upgrade process with well defined steps so that the early adopters don't have to re-create their environments, I think we should go with #2.
+1
On 04/17/2012 04:20 PM, 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?
we also want to push this version of ovirt into fedora (3.0 already in), which will require the native jboss rpms?
Share them with us! --- Ofer Schreiber oVirt Release Manager _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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?
Share them with us! --- Ofer Schreiber oVirt Release Manager _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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. 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. 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".
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
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.
On 18/04/12 13:42, Juan Hernandez wrote:
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 ;-)
nice :), added some comments myself.
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.
Thanks for clarifying 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.
I am interested in 2 flavors as in one using the 'fedora' Jboss and a second one using the upstream Jboss AS we use today. The main reason for that is that we need time for the developers to worked with the Jboss packaged in Fedora and see it does not have major issues. Livnat
On 04/18/2012 01:42 PM, Juan Hernandez wrote: ...
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.
we can include an additional repo for the web ui on top of the engine in fedora 17. still using the jboss in fedora. so no need for an entire additional distro, just the part which is "missing" from F17.
----- 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
participants (5)
-
Itamar Heim -
Juan Hernandez -
Livnat Peer -
Mike Burns -
Ofer Schreiber