Bug 1026447 - The 'ruby' cartridge folder is removed when adding downloadable cartridge to scaled app
The 'ruby' cartridge folder is removed when adding downloadable cartridge to ...
Product: OpenShift Online
Classification: Red Hat
Component: Pod (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lili Nader
libra bugs
: UpcomingRelease
Depends On:
  Show dependency treegraph
Reported: 2013-11-04 11:33 EST by Michal Fojtik
Modified: 2015-05-14 20:22 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-23 22:28:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Fojtik 2013-11-04 11:33:05 EST
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
app-root  hamonitor

--> The 'ruby' folder is gone.

Actual results:

The 'ruby' folder is removed, the gear is not functional (rhc app stop does not work, etc..)

Expected results:

The cartridge should be added successfully and the 'ruby' primary cartridge should not be removed.

Additional info:

Please note, that the downloadable cartridge could be wrong (manifest.yml, bin/scripts...), but this should not happen regardless how bad the cartridge is ;-)
Comment 1 Dan Mace 2013-11-04 13:24:15 EST
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).
Comment 2 Lili Nader 2013-11-05 14:52:37 EST
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.
Comment 3 Lili Nader 2013-11-05 15:40:21 EST
Added check anyway to send an error back if there is an existing web_proxy and the new cartridge is a web_proxy.

Comment 4 Jianwei Hou 2013-11-05 21:20:13 EST
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"

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