Bug 815001
Summary: | Review Request: opennebula - Cloud computing tool to manage a distributed virtual data center to build private, public and hybrid IaaS clouds | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Shawn Starr <shawn.starr> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | dwalsh, james.hogarth, javier.ramirez, jmelis, karlthered, leamas.alec, mattdm, mgrepl, misc, mrunge, nobody, package-review, shawn.starr, valtri |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | NotReady | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-04 04:13:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 201449 |
Description
Shawn Starr
2012-04-22 02:45:48 UTC
There's no SRPM url. Assuming, he meant SRPM: http://fedorapeople.org/~spstarr/packages/opennebula-3.2.1-1.src.rpm Shawn: The fedora-review-flag is set by the reviewer, not the reporter. Well, I set the flag to initiate someone to do the reviewing. It's '?' NO, don't do that. The reviewer sets the flag. http://fedoraproject.org/wiki/Package_Review_Process A few comment - I think the spec layout is rather difficult. While I know everybody has specific preference, I think it would be better to group various %post/%pre script together ( as I missed the one creating oneadmin ) - patches should be commented https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment - is it required to have mysql server on the same computer ? If not, I think the requires could be relaxed. - %setup -q -n opennebula-3.2.1 You should reuse %version, so this is easier to upgrade later - why is the whole .ssh populated in %post, would it better to do it like any other file, with rpm ? ( at least the .ssh/config ), and using %ghost so rpm can manage and check the permission of all file ? - apg is used in a %post script, but the requires is missing ( Requires(post): ) - why do the documentation requires the main packages ? - why do sunstone requires the main package ? According to http://opennebula.org/documentation:archives:rel2.2:sunstone , they can be separated, and I would surely see good reason to deploy them on 2 differents server, for security reason. - From a quick check in open nebula doc, it is not clear why openssh server should be installed on the main hypervisor, could you explain why it is required ? - a oneadmin user is needed on the frontend, but also on the host. So I would suggest to create a package to be used on host that would create the user. This is going to be changing I will be discussing with upstream tomorrow for OpenNebula 3.6 is coming. Thanks for your initial reviews and discussing them with upstream. Spoke to upstream, we will remove the SSH %post section completely and put info in documentation for user. I will clean up .spec accordingly for the other For OpenSSH we need it on hypervisors in order for the oneadmin user to execute commands on the hypervisor and the frontend itself. We will be switching to OpenNebula 3.6 and backporting to Fedora 17 after. Sunstone is a separate package in this .spec file, oZones support will be re-enabled / changed. They do however require opennebula to be installed for ruby/lib dependencies. I will fix the other issues also. This is on hold, targeting Fedora 19 now. Upstream is aware, working with them to sort out issues mentioned in bug. Shawn, any progress here? Are you going to update the spec according to the comments? Some of the changes need to be discussed further with upstream. I'm dealing with personal issues right now, ie, looking for work. I've had no time to look at this unfortunately. This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This is unblocked Upstream is testing out a SELinux solution which should resolve our final issue. [12:33] <@jmelis> I got a tip by nehaljwani [12:33] <@jmelis> telling me that we need to do this: [12:34] <@jmelis> semanage fcontext -a -t ssh_home_t "/var/lib/one/.ssh(/.*)?" ; restorecon -R /var/lib/one/.ssh I will be helping them test on rawhide when they are ready. Then re-review spec file changes as there's been several releases of OpenNebula since. Thanks, Shawn We have the final rubygem (rubygem-parse-cron) in Fedora now for Fedora 19 (pending) and Fedora 20/rawhide. More on this once upstream gets back to me. Upstream is working on SELinux issue which is holding this process up right now. Just so everyone is aware and in the loop: We're working off of this .spec file: https://nazar.karan.org/blob/misc!opennebula/544a11f6ff0d83f6e4eec57479c6b15d72ccc5bb/SPECS!opennebula.spec I have several questions since I'll be taking this and making it Fedora ready. There's some things in the .spec we can't be doing but we can sort these issues out. Any status update here? How about the ruby part? 1) It looks like there are bundled ruby libraries: for example opennebula gem, http://rubygems.org/gems/opennebula. It's from the same project, but other packages may also depend on opennebula rubygem. 2) According to https://fedoraproject.org/wiki/Packaging:Ruby packaging for non-Gem use is no longer needed. In our project we would need to package rubygem-opennebula. It looks like there is not a conflict with this packaging (files are at different locations), but maybe it needs to be cleaned up here or have some coordination? It may be easier to have separated package rubygem-opennebula, but I'm not sure about compatibility of the whole opennebula with different versions of opennebula gem. As per Fedora policy it has been over a year with no response from the requester to a needs info flag. Closing as a dead review. https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews |