Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RPM Build is failing #1116

Closed
ssorenso opened this issue Apr 13, 2017 · 2 comments
Closed

RPM Build is failing #1116

ssorenso opened this issue Apr 13, 2017 · 2 comments
Assignees
@ssorenso
Labels
bug critical

Comments

@ssorenso
Copy link

in this latest release, we're seeing a failure in builds:
Agent Version

f5-openstack-agent-9.3.0-1.el7.noarch.rpm

Operating System

RHEL 7.3

OpenStack Release

RHEL OSP v9 (mitaka)

Description

SDK RPM fails to install due to dependency issue.

[root@isft502 9.3.0]# rpm -qa | grep six
python-six-1.9.0-2.el7.noarch

[root@isft502 9.3.0]# rpm -ivh f5-icontrol-rest-1.3.0-1.el7.noarch.rpm
Preparing... ################################# [100%]
package f5-icontrol-rest-1.3.0-1.noarch is already installed

[root@isft502 9.3.0]# rpm -ivh f5-sdk-2.3.1-1.el7.noarch.rpm
error: Failed dependencies:
f5-icontrol-rest<2.0.0 is needed by f5-sdk-2.3.1-1.noarch
f5-icontrol-rest>=1.3.0 is needed by f5-sdk-2.3.1-1.noarch
six<2.0.0 is needed by f5-sdk-2.3.1-1.noarch
six>=1.9.0 is needed by f5-sdk-2.3.1-1.noarch

Please fix RPM issue. Thanks!
@ssorenso ssorenso self-assigned this Apr 13, 2017
@ssorenso ssorenso added the bug label Apr 13, 2017
@ssorenso
Copy link
Author

ssorenso commented Apr 13, 2017 •
edited
Loading

The overall issue is that the format for RPM's spec file is:
Requires: python-six >= 1.9.0, python-six < 2.0.0, f5-icontrol-rest >= 1.3.0, f5-icontrol-rest < 2.0.0

Instead, the formatting schema that I put into place last February puts this into the format:
Requires: six>=1.9.0 six<2.0.0 ...

Which is not applicable to what we need for RPM packages to work. The reason why this did not outright fail is that the CLI exit status when we issued:
rpm -i
was not raising for a non-zero exit status. This also has to be fixed for the Debian side for the non-zero exit status. It is properly handling its dependencies, though.

ssorenso pushed a commit to ssorenso/f5-common-python that referenced this issue Apr 13, 2017
@sorensF5
Issues:
83b4cfd 
Fixes F5Networks#1116

Problem:
This issue is a few fold:
1. RPM spec file format was not being followed properly
  * Requires: <module> <modifier> <version>, [repeat]
2. RPM was not actually installing dependencies during test
3. RPM was not failing when project package failed to install during test
4. DEB was not actually installing dependencies during test
5. DEB was not fialing when project package failed to install during test

Analysis:
1. added a check_requires() function that will add the proper formatting
  * Change performed in the build-rpm.py
2. Changed the Dependency.cmd to be handled differently with a
Dependency.install_cmd
  * Change performed in the redhat's fetch_and_install_deps.py
3. Fix was multi-fold, but all under redhat's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for rpm -i <project> now has a status check
  * a last verification against rpm -qa is performed
4. Made a Dependency._install_req to be cond. exec. by parent
  * This is always executed by F5Dependency
  * This is added to the ubuntu's fetch_and_install_deps.py
5. Again multi-fold in the ubuntu's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for dpkg -i <project> now has a status check
  * a last verification against dpkg -l is performed

Tests:
This is a test in and of itself; however, there is now an additional
ring of tests for both ubuntu and debian that assures, using its
individual packaging medium, a means to verify that the package is, in
fact, installed after the processing of the test scripts on the
associated docker container instance.
@ssorenso ssorenso mentioned this issue Apr 13, 2017
Merged
ssorenso pushed a commit to ssorenso/f5-common-python that referenced this issue Apr 13, 2017
@sorensF5
Issues:
3fd2219 
Fixes F5Networks#1116

Problem:
This issue is a few fold:
1. RPM spec file format was not being followed properly
  * Requires: <module> <modifier> <version>, [repeat]
2. RPM was not actually installing dependencies during test
3. RPM was not failing when project package failed to install during test
4. DEB was not actually installing dependencies during test
5. DEB was not fialing when project package failed to install during test

Analysis:
1. added a check_requires() function that will add the proper formatting
  * Change performed in the build-rpm.py
2. Changed the Dependency.cmd to be handled differently with a
Dependency.install_cmd
  * Change performed in the redhat's fetch_and_install_deps.py
3. Fix was multi-fold, but all under redhat's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for rpm -i <project> now has a status check
  * a last verification against rpm -qa is performed
4. Made a Dependency._install_req to be cond. exec. by parent
  * This is always executed by F5Dependency
  * This is added to the ubuntu's fetch_and_install_deps.py
5. Again multi-fold in the ubuntu's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for dpkg -i <project> now has a status check
  * a last verification against dpkg -l is performed

Tests:
This is a test in and of itself; however, there is now an additional
ring of tests for both ubuntu and debian that assures, using its
individual packaging medium, a means to verify that the package is, in
fact, installed after the processing of the test scripts on the
associated docker container instance.
ssorenso pushed a commit to ssorenso/f5-common-python that referenced this issue Apr 13, 2017
@sorensF5
Issues:
bff5816 
Fixes F5Networks#1116

Problem:
This issue is a few fold:
1. RPM spec file format was not being followed properly
  * Requires: <module> <modifier> <version>, [repeat]
2. RPM was not actually installing dependencies during test
3. RPM was not failing when project package failed to install during test
4. DEB was not actually installing dependencies during test
5. DEB was not fialing when project package failed to install during test

Analysis:
1. added a check_requires() function that will add the proper formatting
  * Change performed in the build-rpm.py
2. Changed the Dependency.cmd to be handled differently with a
Dependency.install_cmd
  * Change performed in the redhat's fetch_and_install_deps.py
3. Fix was multi-fold, but all under redhat's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for rpm -i <project> now has a status check
  * a last verification against rpm -qa is performed
4. Made a Dependency._install_req to be cond. exec. by parent
  * This is always executed by F5Dependency
  * This is added to the ubuntu's fetch_and_install_deps.py
5. Again multi-fold in the ubuntu's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for dpkg -i <project> now has a status check
  * a last verification against dpkg -l is performed

Tests:
This is a test in and of itself; however, there is now an additional
ring of tests for both ubuntu and debian that assures, using its
individual packaging medium, a means to verify that the package is, in
fact, installed after the processing of the test scripts on the
associated docker container instance.
ssorenso pushed a commit to ssorenso/f5-common-python that referenced this issue Apr 14, 2017
@sorensF5
Issues:
f508d9f 
Fixes F5Networks#1116

Problem:
This issue is a few fold:
1. RPM spec file format was not being followed properly
  * Requires: <module> <modifier> <version>, [repeat]
2. RPM was not actually installing dependencies during test
3. RPM was not failing when project package failed to install during test
4. DEB was not actually installing dependencies during test
5. DEB was not fialing when project package failed to install during test

Analysis:
1. added a check_requires() function that will add the proper formatting
  * Change performed in the build-rpm.py
2. Changed the Dependency.cmd to be handled differently with a
Dependency.install_cmd
  * Change performed in the redhat's fetch_and_install_deps.py
3. Fix was multi-fold, but all under redhat's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for rpm -i <project> now has a status check
  * a last verification against rpm -qa is performed
4. Made a Dependency._install_req to be cond. exec. by parent
  * This is always executed by F5Dependency
  * This is added to the ubuntu's fetch_and_install_deps.py
5. Again multi-fold in the ubuntu's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for dpkg -i <project> now has a status check
  * a last verification against dpkg -l is performed

Tests:
This is a test in and of itself; however, there is now an additional
ring of tests for both ubuntu and debian that assures, using its
individual packaging medium, a means to verify that the package is, in
fact, installed after the processing of the test scripts on the
associated docker container instance.
@jgruber
Copy link
Contributor

jgruber commented Apr 17, 2017

Added critical tag as it is a blocking issue for private cloud use cases A2 and A3.

It also blocks ESD release for OpenStack LBaaSv2.

ssorenso pushed a commit to ssorenso/f5-common-python that referenced this issue Apr 19, 2017
@sorensF5
Issues:
82c2f47 
Fixes F5Networks#1116

Problem:
This issue is a few fold:
1. RPM spec file format was not being followed properly
  * Requires: <module> <modifier> <version>, [repeat]
2. RPM was not actually installing dependencies during test
3. RPM was not failing when project package failed to install during test
4. DEB was not actually installing dependencies during test
5. DEB was not fialing when project package failed to install during test

Analysis:
1. added a check_requires() function that will add the proper formatting
  * Change performed in the build-rpm.py
2. Changed the Dependency.cmd to be handled differently with a
Dependency.install_cmd
  * Change performed in the redhat's fetch_and_install_deps.py
3. Fix was multi-fold, but all under redhat's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for rpm -i <project> now has a status check
  * a last verification against rpm -qa is performed
4. Made a Dependency._install_req to be cond. exec. by parent
  * This is always executed by F5Dependency
  * This is added to the ubuntu's fetch_and_install_deps.py
5. Again multi-fold in the ubuntu's fetch_and_install_deps.py:
  * runCommand() was changed to use subprocess.check_output
  * runCommand()'s call for dpkg -i <project> now has a status check
  * a last verification against dpkg -l is performed

Tests:
This is a test in and of itself; however, there is now an additional
ring of tests for both ubuntu and debian that assures, using its
individual packaging medium, a means to verify that the package is, in
fact, installed after the processing of the test scripts on the
associated docker container instance.
wojtek0806 added a commit that referenced this issue May 4, 2017
@wojtek0806
Merge pull request #1117 from ssorenso/feature.packaging_error_1116
6a555e6 
Issues: #1116 - Multi-step fix for RPM and DEB package validation
This was referenced May 12, 2017
Merged
Merged
@pjbreaux pjbreaux mentioned this issue May 23, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ssorenso ssorenso

Labels
bug critical
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jgruber @ssorenso