Bug 986112 - PostgreSQL 8.4 should not be listed among the available cartridges if PostgreSQL 9.2 is added to the app
Summary: PostgreSQL 8.4 should not be listed among the available cartridges if Postgre...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Pod
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Clayton Coleman
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-19 01:53 UTC by Hiro Asari
Modified: 2015-06-11 21:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-11 21:09:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Hiro Asari 2013-07-19 01:53:44 UTC
Description of problem:
If the application railspg has PostgreSQL 9.2 embedded,
https://openshift.redhat.com/app/console/application/railspg/cartridge_types
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:
Always

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 20:38:51 UTC
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-08 00:25:36 UTC
Clayton,

  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 16:51:40 UTC
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.