Hello, I recently came across the LWN article on oVirt 3.4 (http://lwn.net/SubscriberLink/600370/dfa9cdd4f5ee0bb3/) and was discussing the lack of Fedora 20 support with an oVirt contributor, bkp. It's been 4 months since I last looked at running oVirt. I use Fedora 20 on all of my infrastructure, so I was quite surprised that there is still not support for running the engine on F20. Anyways, rather than just complaining, I figured it would be more helpful to volunteer some time to fix the issue. 1) I've tried looking through the oVirt bug reports to see what's happening with Fedora 20. So far, I have identified three issues that prevent 3.4 from working. Fedora includes sos-3, sos doesn't have support for all ovirt plugins, and only has Wildfly instead of JBoss-as. The full list of bugs is listed in https://bugzilla.redhat.com/show_bug.cgi?id=1060198. 2) I was looking through the various oVirt yum repositories and noticed that oVirt provides JBoss-AS along with tons of packages for the el6 platform; however, for both Fedora 19 and 20, oVirt almost entirely uses built-in packages. This seems like strange behavior where the project has gone to great lengths to make sure oVirt works on platforms with outdated or nonexistent packages, but won't override or use alternates on platforms that contain overly new packages. Could someone explain why oVirt doesn't package these for Fedora, particularly jboss-as? 3) I'm not making accusations or trying to cause trouble, but could someone explain to an outsider what happened with Fedora 20 support? oVirt is a complicated project to say the least and, after a brief look at some of the RPMs last night, the packages are just as complex. Basically, I'm trying to figure out if there were some intractable problems that prevented oVirt from -- more or less -- shipping tweaked Fedora 19 dependencies for oVirt on Fedors 20, or whether it was more a lack of manpower, a lack of interested user base, or perhaps I'm just getting started on digesting the packages, but I think it should be feasible to pull the problematic packages from F19, tweak them to ovirt-* versions (eg. ovirt-sos), and tweak the oVirt packages to use the non-system paths for those packages. Publish the whole thing through COPR, and if oVirt is happy with the results, merge them into the official packages and repository. I know that there will be some apprehension about the project taking on maintaining these dependency packages, but I'm looking to get 3.4 working on Fedora 20 as a stopgap until 3.5 is released with support for native packages. Thoughts? Thanks, Justin
Il 02/giu/2014 20:59 "Justin Brown"
I know that there will be some apprehension about the project taking on maintaining these dependency packages, but I'm looking to get 3.4 working on Fedora 20 as a stopgap until 3.5 is released with support for native packages.
Thoughts?
Thanks, Justin
Glad and available to help, both on list and off list, both on testing and packaging ( I have decent experience in this second one). Gianluca
On 06/02/2014 09:59 PM, Justin Brown wrote:
Hello,
I recently came across the LWN article on oVirt 3.4 (http://lwn.net/SubscriberLink/600370/dfa9cdd4f5ee0bb3/) and was discussing the lack of Fedora 20 support with an oVirt contributor, bkp.
It's been 4 months since I last looked at running oVirt. I use Fedora 20 on all of my infrastructure, so I was quite surprised that there is still not support for running the engine on F20. Anyways, rather than just complaining, I figured it would be more helpful to volunteer some time to fix the issue.
1) I've tried looking through the oVirt bug reports to see what's happening with Fedora 20. So far, I have identified three issues that prevent 3.4 from working. Fedora includes sos-3, sos doesn't have support for all ovirt plugins, and only has Wildfly instead of JBoss-as. The full list of bugs is listed in https://bugzilla.redhat.com/show_bug.cgi?id=1060198.
2) I was looking through the various oVirt yum repositories and noticed that oVirt provides JBoss-AS along with tons of packages for the el6 platform; however, for both Fedora 19 and 20, oVirt almost entirely uses built-in packages. This seems like strange behavior where the project has gone to great lengths to make sure oVirt works on platforms with outdated or nonexistent packages, but won't override or use alternates on platforms that contain overly new packages. Could someone explain why oVirt doesn't package these for Fedora, particularly jboss-as?
3) I'm not making accusations or trying to cause trouble, but could someone explain to an outsider what happened with Fedora 20 support? oVirt is a complicated project to say the least and, after a brief look at some of the RPMs last night, the packages are just as complex. Basically, I'm trying to figure out if there were some intractable problems that prevented oVirt from -- more or less -- shipping tweaked Fedora 19 dependencies for oVirt on Fedors 20, or whether it was more a lack of manpower, a lack of interested user base, or perhaps
I'm just getting started on digesting the packages, but I think it should be feasible to pull the problematic packages from F19, tweak them to ovirt-* versions (eg. ovirt-sos), and tweak the oVirt packages to use the non-system paths for those packages. Publish the whole thing through COPR, and if oVirt is happy with the results, merge them into the official packages and repository.
yes, should be feasible just using the 'blob' approach of the .el6 jboss-as rpm for fedora 20, which is the current plan. we'd love help with doing/testing this of course.
I know that there will be some apprehension about the project taking on maintaining these dependency packages, but I'm looking to get 3.4 working on Fedora 20 as a stopgap until 3.5 is released with support for native packages.
Thoughts?
Thanks, Justin _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
2014-06-03 2:59 GMT+08:00 Justin Brown <justin.brown@fandingo.org>:
Hello,
I recently came across the LWN article on oVirt 3.4 (http://lwn.net/SubscriberLink/600370/dfa9cdd4f5ee0bb3/) and was discussing the lack of Fedora 20 support with an oVirt contributor, bkp.
It's been 4 months since I last looked at running oVirt. I use Fedora 20 on all of my infrastructure, so I was quite surprised that there is still not support for running the engine on F20. Anyways, rather than just complaining, I figured it would be more helpful to volunteer some time to fix the issue.
1) I've tried looking through the oVirt bug reports to see what's happening with Fedora 20. So far, I have identified three issues that prevent 3.4 from working. Fedora includes sos-3, sos doesn't have support for all ovirt plugins, and only has Wildfly instead of JBoss-as. The full list of bugs is listed in https://bugzilla.redhat.com/show_bug.cgi?id=1060198.
2) I was looking through the various oVirt yum repositories and noticed that oVirt provides JBoss-AS along with tons of packages for the el6 platform; however, for both Fedora 19 and 20, oVirt almost entirely uses built-in packages. This seems like strange behavior where the project has gone to great lengths to make sure oVirt works on platforms with outdated or nonexistent packages, but won't override or use alternates on platforms that contain overly new packages. Could someone explain why oVirt doesn't package these for Fedora, particularly jboss-as?
IMO fedora is more like a environment for development purpose, and I guess oVirt didn't catch up with fedora's changes ? (I mean oVirt don't have support for wildfly)
3) I'm not making accusations or trying to cause trouble, but could someone explain to an outsider what happened with Fedora 20 support? oVirt is a complicated project to say the least and, after a brief look at some of the RPMs last night, the packages are just as complex. Basically, I'm trying to figure out if there were some intractable problems that prevented oVirt from -- more or less -- shipping tweaked Fedora 19 dependencies for oVirt on Fedors 20, or whether it was more a lack of manpower, a lack of interested user base, or perhaps
I'm just getting started on digesting the packages, but I think it should be feasible to pull the problematic packages from F19, tweak them to ovirt-* versions (eg. ovirt-sos), and tweak the oVirt packages to use the non-system paths for those packages. Publish the whole thing through COPR, and if oVirt is happy with the results, merge them into the official packages and repository.
I know that there will be some apprehension about the project taking on maintaining these dependency packages, but I'm looking to get 3.4 working on Fedora 20 as a stopgap until 3.5 is released with support for native packages.
Thoughts?
Thanks, Justin _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Justin Brown" <justin.brown@fandingo.org> To: users@ovirt.org Sent: Monday, June 2, 2014 9:59:34 PM Subject: [ovirt-users] Adding Fedora 20 Support
Hello,
I recently came across the LWN article on oVirt 3.4 (http://lwn.net/SubscriberLink/600370/dfa9cdd4f5ee0bb3/) and was discussing the lack of Fedora 20 support with an oVirt contributor, bkp.
It's been 4 months since I last looked at running oVirt. I use Fedora 20 on all of my infrastructure, so I was quite surprised that there is still not support for running the engine on F20. Anyways, rather than just complaining, I figured it would be more helpful to volunteer some time to fix the issue.
1) I've tried looking through the oVirt bug reports to see what's happening with Fedora 20. So far, I have identified three issues that prevent 3.4 from working. Fedora includes sos-3, sos doesn't have support for all ovirt plugins, and only has Wildfly instead of JBoss-as. The full list of bugs is listed in https://bugzilla.redhat.com/show_bug.cgi?id=1060198.
This is a tracker bug, depending on various other bugs. One of them is https://bugzilla.redhat.com/show_bug.cgi?id=1055604 . As can be seen there, it was intended to be supported in 3.4.2, but was then reverted due to last-minute issues. -- Didi
participants (5)
-
Gianluca Cecchi -
Itamar Heim -
Justin Brown -
plysan -
Yedidyah Bar David