Description of problem: If I specify an older version of dependency, when I git push for the second time, building process try to update the dependency, the dependency will be updated unsuccessfully. Finally fail to git push the app Version-Release number of selected component (if applicable): puddle:[1.2.7/2013-12-16.3] How reproducible: always Steps to Reproduce: 1.create a php app #rhc create app phpapp php 2.add dependency to the app, and git push #echo "Validate-0.8.4" >> deplist.txt #git commit -amx && git push 3.do some changes, then git push again Actual results: Output: remote: CLIENT_MESSAGE: Stopping Apache+mod_php HTTPD server remote: Waiting for stop to finish remote: Checking pear: Validate-0.8.4 remote: remote: pear/Validate is already installed and is the same as the released version 0.8.4 remote: upgrade failed remote: An error occurred executing 'gear postreceive' remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh://52c2821e2fde571cff0003b3.com.cn/~/git/phpapp.git/ 8fada45..13e0d74 master -> master Expected results: Should git push successfully for the second time Additional info: vim /usr/libexec/openshift/cartridges/v2/php/bin/control 53 function build() { 54 if [ -f "${OPENSHIFT_REPO_DIR}/.openshift/markers/force_clean_build" ] 55 then 56 echo ".openshift/markers/force_clean_build found! Recreating pear libs" 1>&2 57 rm -rf "${OPENSHIFT_PHP_DIR}"/phplib/pear/* 58 mkdir -p "${OPENSHIFT_PHP_DIR}"/phplib/pear/{docs,ext,php,cache,cfg,data,download,temp,tests,www} 59 fi 60 61 if [ -f ${OPENSHIFT_REPO_DIR}deplist.txt ] 62 then 63 for f in $(cat ${OPENSHIFT_REPO_DIR}deplist.txt) 64 do 65 echo "Checking pear: $f" 66 echo 67 if pear list "$f" > /dev/null 68 then 69 pear upgrade "$f" 70 elif ! ( php -c "${OPENSHIFT_PHP_DIR}"/conf -m | grep -i -q \^`basename "$f"`\$ ) 71 then 72 pear install --alldeps "$f" 73 else 74 echo "Extension already installed in the system: $f" 75 fi 76 done 77 fi In the line 69, the function update dependency unsuccessfully!!
This definitely works in 2.0. If the problem still exists in 1.2 please reopen.
Actually, I read the description more closely, it's only reproduceable if the dependency already exists on the system (say from an RPM). I tested with MDB2-2.4.1 and I was able to reproduce this on 2.x.
check it on puddle [1.2.4/2014-01-29.2] 1.setup the test env 2..create a php app #rhc create app phpapp php 3.add dependency to the app, and git push #echo "Validate-0.8.4" >> deplist.txt #git commit -amx && git push 4.do some changes, then git push again Output: <--snip--> remote: Waiting for stop to finish remote: Checking pear: Validate-0.8.4 remote: remote: pear/Validate is already installed and is the same as the released version 0.8.4 remote: upgrade failed remote: An error occurred executing 'gear postreceive' remote: remote: For more details about the problem, try running the command again with the '--trace' option. To ssh://52f4bb5f490604f882000005.com/~/git/phpapp.git/ 0e22eff..716d38b master -> master If the dependency is the latest version, we can reproduce this problem.
with the current devenv_5011 the git push doesn't fail but still can't downgrade a package once a newer version already installed. <--snip--> remote: Waiting for stop to finish remote: Building git ref 'master', commit e754cda remote: Checking .openshift/pear.txt for PEAR dependency... remote: Checking PEAR: Validate-0.8.3 remote: remote: pear/Validate is already installed and is newer than detected released version 0.8.3 remote: upgrade failed remote: remote: Preparing build for deployment remote: Deployment id is 2f948482 remote: Activating deployment remote: Starting PHP 5.4 cartridge (Apache+mod_php) <--snip--> Is this a valid use-case? The workaround I found is to clear the contents of app-root/runtime/dependencies/php/phplib/pear/pear folder to reinstall all dependencies.
Thanks for looking at this upstream Balazs. We need to support developers setting whatever version they want. I'm not familiar with pear. Is there something special about downgrading a dependency with pear?
Hi Brenton, I looked into it and we have an official way to do this. If the user would like to downgrade a package then he should use "force_clean_build" marker [1]. Currently we checking only if the package is already installed, if so then we call pear upgrade, if not then install. I'm neither experienced with Pear but according to the docs, it can't handle downgrades well[2]. [1]: https://github.com/openshift/origin-server/blob/master/cartridges/openshift-origin-cartridge-php/bin/control#L93 [2]: http://pear.php.net/manual/en/guide.users.commandline.installing.php
I'm guessing the "pear/Validate is already installed and is newer than detected released" is coming from pear. As you mention, googling for "php pear downgrade package" does make it seem that pear doesn't handle downgrades well. Unless that "feature" and our force_clean_build marker is widely known in the php community I would hope we could hide this from the developer. The best experience would be for us to force the clean build automatically if we can detect this. If that's ugly to implement we could simply print a warning message telling the developer how to force a clean build with our marker file. What do you think?
So the test cases here are: 1. Install a dep which wasn't installed before (with or without specified version) expected: it installs cleanly, without errors 2. A dep specified in a pear.txt without version (ex. "Validate") expected: it always calls upgrade on the package 3. A dep specified with version (ex. "Validate-0.8.3") 3.1 the dep is already installed and it's the same version (ex.: user change his app's code) expected: it shouldn't call upgrade and it shouldn't print upgrade failed message 3.2 the dep is already installed and it's a newer version expected: it calls upgrade and do it without error or further notice 3.3 the dep is already installed and it's a downgrade expected: the upgrade failed message appears and a message about how to do a clean build (force_clean_build marker) I made a PR which fulfills these requirements: https://github.com/openshift/origin-server/pull/5681
That sounds great Balazs. Mind creating a fork ami for QE to test this in an Online devenv before we cherry-pick it into Enterprise?
It merged into master: https://github.com/openshift/origin-server/commit/12ed278a09a7055b59f44ef50acda313e91c4b58 Do I still need to create a fork ami?
No, however if you wanted QE to test it in Online explicitly you might want to clone this bug.
QA helped me to test it, there is still one issue: https://bugzilla.redhat.com/show_bug.cgi?id=1126323#c3
It looks like the fix for this defect was shipped in RHSA-2014:1796 "Red Hat OpenShift Enterprise 2.2 Release Advisory". QE, can you please verify that the defect does not exist in OpenShift Enterprise 2.2?
Check on puddle [2.2.7/2015-09-18.2] deploy the app successfully remote: Stopping PHP 5.4 cartridge (Apache+mod_php) remote: Waiting for stop to finish remote: Waiting for stop to finish remote: Waiting for stop to finish remote: Syncing git content to other proxy gears remote: Building git ref 'master', commit 676d3ec remote: It appears you have a deplist.txt and .openshift/pear.txt file. remote: Please consider running `git rm deplist.txt'. remote: Checking .openshift/pear.txt for PEAR dependency... remote: Checking PEAR: Validate-0.8.4 remote: remote: Failed to download pear/Net_IDNA within preferred state "stable", latest release is version 0.8.1, stability "beta", use "channel://pear.php.net/Net_IDNA-0.8.1" to install remote: pear/Validate can optionally use package "pear/Net_IDNA" (version >= 0.7.1) remote: downloading Validate-0.8.4.tgz ... remote: Starting to download Validate-0.8.4.tgz (20,809 bytes) remote: ........done: 20,809 bytes remote: downloading Date-1.4.7.tgz ... remote: Starting to download Date-1.4.7.tgz (55,754 bytes) remote: ...done: 55,754 bytes remote: install ok: channel://pear.php.net/Validate-0.8.4 remote: install ok: channel://pear.php.net/Date-1.4.7 remote: remote: Preparing build for deployment
This fix is available in OpenShift Enterprise 3.1.