Bug 1077591 - Fail to restore a new python-2.7 app containing custom python scripts without rebuilding the app
Summary: Fail to restore a new python-2.7 app containing custom python scripts without...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Michal Fojtik
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-18 09:45 UTC by Zhe Wang
Modified: 2015-05-15 00:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-09 15:24:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
wsgi.py (6.87 KB, text/x-python)
2014-03-18 09:46 UTC, Zhe Wang
no flags Details
mysql_factory.py (1.07 KB, text/x-python)
2014-03-18 09:46 UTC, Zhe Wang
no flags Details

Description Zhe Wang 2014-03-18 09:45:29 UTC
Description of problem:
Given a new python-2.7 app (app2) with some custom python scripts, for example, a python script of connecting MySQL db, when restoring this app from an existing tarball with the same repo content (say, from app1), the restoration to app2 fails to locate the customer python scripts without re-deploying app2.

Version-Release number of selected component (if applicable):
devenv_4526

How reproducible:
always

Steps to Reproduce:
1. create a Python-2.7 app (app1) with MySQL-5.1 added, and write a simple connector (mysql_factory.py) to the db (see the attachments: wsgi.py and mysql_factory.py)

2. push the change

3. check if the custom script works. In this example, visiting <app1_url>/mysql, and check if it returns "version 1".

4. create a snapshot of app1

5. create a new python-2.7 app (app2) with mysql-5.1 added

6. restore app2 from the snapshot of app1

7. check if the restoration works by visiting <app2_url>/mysql

8. check if the db connector is in the repo of app2

9. make some change in the repo of app2 and push the change

10. repeat Step 7

Actual results:
In step 6, the restoration succeeds, but it fails to connect fetch the records in the mysql db of app2, with the error:

No module named mysql_factory

Step 7 confirms that mysql_factory.py is restored to the repo of app2, 

[py271-tjnvpu.dev.rhcloud.com 532805c53b36e4fd7e00045d]\> find . -name mysql_factory.py
./app-deployments/2014-03-18_04-35-21.960/repo/mysql_factory.py
./app-root/runtime/repo/mysql_factory.py
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


and after rebuilding app2, the connection to the mysql db in app2 via the custom script works.

Expected results:
The restoration should take effect immediately without rebuilding app2.

Additional info:

Comment 1 Zhe Wang 2014-03-18 09:46:13 UTC
Created attachment 875843 [details]
wsgi.py

Comment 2 Zhe Wang 2014-03-18 09:46:43 UTC
Created attachment 875844 [details]
mysql_factory.py

Comment 4 Michal Fojtik 2014-03-18 17:23:27 UTC
I'm kind of stuck on this one for now. The problem seems that after restore the Apache/WSIG is not restarted and so the mysql_factory.py is not compiled.
I added 'post-restore' hook into control script to trigger the restart (if I do this manually via rhc ssh it works). For some reason this hook is not being executed on latest devenv. I will investigate this later tomorrow.

If this is not regression from last sprint, I would set this one as UpcomingRelease.

Comment 5 Michal Fojtik 2014-03-19 14:29:04 UTC
The fix is here, it is regression from previous sprint where we forget to update performance.conf for python cartridge.

https://github.com/openshift/origin-server/pull/5000

Comment 6 openshift-github-bot 2014-03-19 15:00:48 UTC
Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/4751f9b1c237ff4e5ed577cb05e0503a39194c1b
Bug 1077591 - Add OPENSHIFT_REPO_DIR to python-path in wsgi

Comment 7 Zhe Wang 2014-03-20 07:09:28 UTC
Verified in both devenv_4540 and STG(devenv-stage_758) with the identical steps in the description, covering python-2.6, 2.7 and 3.3. After restoring without rebuilding the app, the custom scripts are usable.


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