Red Hat Bugzilla – Bug 1232759
Fork sos for RHEL OSP use with RHEL 7.1.z
Last modified: 2015-08-05 09:27:25 EDT
Description of problem: Fork sos for RHEL OSP use with RHEL 7.1.z. Version-Release number of selected component (if applicable): sos-3.2-15.el7_1.5 Additional info: This fork will be maintained until the release of RHEL 7.2, at which point we will revert back to using the RHEL provided sos package.
It would be helpful if the bug description explained why a "fork" is necessary; what is missing from upstream/7.1 sos that will be provided here? What will be the differences between the "fork" and a regular 7.1.z build? And do we really needs this if we can get OSP's needs pushed through to the main 7.1.z?
(In reply to Bryn M. Reeves from comment #3) > It would be helpful if the bug description explained why a "fork" is > necessary; Apologies Bryn! To ensure that we have plugins in place covering the various components of the currently under development director (deployment) tool. This tool is actually made up of a whole range of components, the interfaces for which are under intense development. > what is missing from upstream/7.1 sos that will be provided here? - New plugins for ironic, instack, tripleo and heat_agents. All WIP at present. - Limited improvements to the core openstack_ plugins where required. > What will be the differences between the "fork" and a regular 7.1.z build? _Only_ the above plugin changes, no changes to the core of sosreport will be made. We will rebase the fork *if* required to pull in changes to the core of sosreport. I had planned on tracking all changes for this fork in BZs against this RHEL OSP sos component with additional RHEL 7.2 sos BZs tracking the changes back into RHEL. This BZ is only to track the initial build and release of the fork. > And do we really needs this if we can get OSP's needs pushed through to the > main 7.1.z? No, we would not but again given the aggressive development of the director I feel that forking here will save the core sos team cycles and pain in trying to schedule errata in line with RHEL OSP release dates in a very short amount of time. By shipping the fork with OSP we automatically sync to their release cycles during this time.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2015:1548