Bug 986112 - PostgreSQL 8.4 should not be listed among the available cartridges if PostgreSQL 9.2 is added to the app
PostgreSQL 8.4 should not be listed among the available cartridges if Postgre...
Product: OpenShift Online
Classification: Red Hat
Component: Pod (Show other bugs)
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Clayton Coleman
libra bugs
Depends On:
  Show dependency treegraph
Reported: 2013-07-18 21:53 EDT by Hiro Asari
Modified: 2015-06-11 17:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-06-11 17:09:59 EDT
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 Hiro Asari 2013-07-18 21:53:44 EDT
Description of problem:
If the application railspg has PostgreSQL 9.2 embedded,
lists PostgreSQL 8.4 as an available cartridge.

Adding the 8.4 cartridge always fails, so this display is misleading at best.

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

How reproducible:

Steps to Reproduce:
1. rhc app create foo ruby-1.9 postgresql-9.2
2. https://openshift.redhat.com/app/console/application/foo/cartridge_types

Actual results:
PostgreSQL 8.4 is listed.

Expected results:
PostgreSQL 8.4 should not be listed.

Additional info:
While I have not tried it, if the app has PostgreSQL 8.4 embedded, I suspect PostgreSQL 9.2 would be displayed.
Comment 1 Clayton Coleman 2013-08-21 16:38:51 EDT
Broker has to tell the UI via a REST API response on the /cartridges call whether a cart has a prereq or exclusion.
Comment 3 Dan McPherson 2014-02-07 19:25:36 EST

  Are you suggesting returning exclusions as part of application/<app>/cartridges or as part of rest/cartridges?

  It's an OpenShift restriction that you can only have 1 cart per cart name installed per app.  Do we really need an extra field for this?
Comment 4 Clayton Coleman 2014-02-08 11:51:40 EST
So the problem is that the only way a client can tell the restriction exists is to apply arbitrary rules from the client.  That means those arbitrary rules have to be communicated to all client teams whenever they change (and have to maintain backward compatibility).  1 cart base name per gear is a bit arbitrary and probably won't persist into docker, so I would argue that if there are conflicts we return them as:

  conflicts: ["name1", "name2"] 

where each conflicting name is listed.  It's better for an API to describe what can't be done and let the client react.

However, do I care enough about this to say we need to fix it prior to docker?  No.

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