Red Hat Bugzilla – Bug 1026447
The 'ruby' cartridge folder is removed when adding downloadable cartridge to scaled app
Last modified: 2015-05-14 20:22:49 EDT
Description of problem:
I tried to add my downloadable cartridge to a scaled Ruby 1.9 application and the 'ruby' folder inside the gear was removed after the cartridge was successfully added.
The 'ruby' folder was there before, so I suspect something must remove that folder during the cartridge installation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ rhc app create mon01 ruby-1.9 -s
2. $ rhc ssh --app mon01
* Verify that the 'ruby' folder is there.
3. $ rhc add-cartridge https://raw.github.com/mfojtik/openshift-origin-cartridge-hamonitor/master/metadata/manifest.yml --app mon01
4. $ rhc ssh --app mon01
[mon01-mfojtik.rhcloud.com 5277c2355004465a1400041b]\> ls
--> The 'ruby' folder is gone.
The 'ruby' folder is removed, the gear is not functional (rhc app stop does not work, etc..)
The cartridge should be added successfully and the 'ruby' primary cartridge should not be removed.
Please note, that the downloadable cartridge could be wrong (manifest.yml, bin/scripts...), but this should not happen regardless how bad the cartridge is ;-)
Following the same steps in devenv_3984, I got even more serious behavior. During the `add-cartridge` call, the broker sends an `app-create` action to the node (equivalent to that which was used to create the app initially), which fails (due to the uuid/gear already existing), causing a subsequent rollback/app-delete from the broker, deleting the app entirely.
Looks like the broker is not sending the correct action to the node (and in this case should likely invalidate the user request to begin with since the app already contains a web_proxy cart).
It was thought that the downloadable cartridge and hence it conflicted with the haproxy already in place for a scalable app. However, he manifest does not show a category as web_proxy. Maybe it was changed in the mean time. I could not reproduce the bug.
Added check anyway to send an error back if there is an existing web_proxy and the new cartridge is a web_proxy.
Tested on devenv_3993, didn't reproduce this problem again.
Try to add a custom cartridge with web_framwork category, client will show up "You can only have one framework cartridge in your application"