Bug 1314546 - Python cartridge doesn't stop deploy process when it failed to install packages (It is different from behavior of other cartridges)
Python cartridge doesn't stop deploy process when it failed to install packag...
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Deployments (Show other bugs)
2.2.0
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Vu Dinh
Gaoyun Pei
:
Depends On: 1303796
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-03 16:20 EST by Rory Thrasher
Modified: 2016-03-22 12:55 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The build process in control script doesn't catch all failed operations during the process of installing required packages in requirements.txt. Consequence: If a required package installation fails, the deployment process will continue. Fix: The control script is modified to catch all failures that may occur during the build process. Result: If a required package fails to be installed, the deployment process is terminated.
Story Points: ---
Clone Of: 1303796
Environment:
Last Closed: 2016-03-22 12:55:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 3 Rory Thrasher 2016-03-03 17:36:24 EST
QA,

I know this was tested earlier for online, but can we verify based on the steps to reproduce that this is fixed in the latest puddle as well? Thank you.

Puddle: http://etherpad.corp.redhat.com/puddle-2-2-2016-02-19
Comment 4 Gaoyun Pei 2016-03-07 00:39:23 EST
Verify this bug with puddle 2.2/2016-03-03.1

With python-2.6/2.7/3.3 apps:

1. Put *wrong* package down requirements.txt.

e.g: foo==1.1.1 (the package 'foo' doesn't exist)

  foo==1.1.1
  Django==1.7.4
  Pillow==2.6.1
  ...

2. Deploy test

  $ git commit -am "package test" && git push
 
...
remote: No distributions at all found for foo==1.1.1 (from -r /var/lib/openshift/123-app1-1/app-root/runtime/repo/requirements.txt (line 1))
remote: Traceback (most recent call last):
remote:   File "/var/lib/openshift/123-app1-1/python/virtenv/bin/pip", line 12, in <module>
remote:     load_entry_point('pip==1.4', 'console_scripts', 'pip')()
remote:   File "/var/lib/openshift/123-app1-1/app-root/runtime/dependencies/python/virtenv/lib/python2.7/site-packages/pip/__init__.py", line 147, in main
remote:     return command.main(args[1:], options)
remote:   File "/var/lib/openshift/123-app1-1/app-root/runtime/dependencies/python/virtenv/lib/python2.7/site-packages/pip/basecommand.py", line 171, in main
remote:     log_fp = open_logfile(log_fn, 'w')
remote:   File "/var/lib/openshift/123-app1-1/app-root/runtime/dependencies/python/virtenv/lib/python2.7/site-packages/pip/basecommand.py", line 200, in open_logfile
remote:     os.makedirs(dirname)
remote:   File "/var/lib/openshift/123-app1-1/python/virtenv/lib64/python2.7/os.py", line 157, in makedirs
remote:     mkdir(name, mode)
remote: OSError: [Errno 13] Permission denied: '/var/lib/openshift/123-app1-1/.pip'
remote: An error occurred executing 'gear postreceive' (exit code: 1)
remote: Error message: CLIENT_ERROR: Failed to execute: 'control build' for /var/lib/openshift/123-app1-1/python
remote:
remote: For more details about the problem, try running the command again with the '--trace' option.
To ssh://123-app1-1@app1-123.ose22-auto.com.cn/~/git/app1.git/
   16df7d9..a24ad03  master -> master
Comment 6 errata-xmlrpc 2016-03-22 12:55:34 EDT
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://rhn.redhat.com/errata/RHSA-2016-0489.html

Note You need to log in before you can comment on or make changes to this bug.