Bug 1991702 - Service Binding Operator - two API selections with the same name
Summary: Service Binding Operator - two API selections with the same name
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Dev Console
Version: 4.9
Hardware: s390x
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: cvogt
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-09 18:23 UTC by jhusta
Modified: 2021-09-22 15:28 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-22 15:28:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screen shots of web-console (94.43 KB, application/pdf)
2021-08-09 18:29 UTC, jhusta
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github redhat-developer service-binding-operator pull 1009 0 None None None 2021-08-23 17:39:49 UTC

Description jhusta 2021-08-09 18:23:42 UTC
Description of problem:
Service Binding Operator has two APIs named Service Binding Operator.
1. it is not clear what the difference is between the two
2. if you want to have two different APIs selectable via the web-console there should be a difference in the naming.

From the UI you will have multiple tabs from the interface with the same name.
When creating a Service Binding Operator you will get a pull down with identical name selection. I will attach some screen shots with these references.

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


How reproducible:
Install the service binding Operator from the Web Console
Note two APIS with the same name
Goto the All instances tab and select Create new you will also get two selections with the same name.

I would like to know if there is supposed to be 2 different APIs and if so having a clear definition of the two and how they differ along with names differentiating between them for the naming of the tabs on the Operator panel as well as any drop down selections.

I am testing this on Z and don't have access to any other architectures for comparison. 




Steps to Reproduce:
1.See above
2.
3.

Actual results:


Expected results:
See above comments on expectations


Additional info:

Comment 1 jhusta 2021-08-09 18:29:30 UTC
Created attachment 1812538 [details]
screen shots of web-console

Comment 2 Jon Jackson 2021-08-11 13:33:33 UTC
Moving to dev console. This is a bug with the Service Binding operator as the display names are defined on the CSV.

Comment 3 Samuel Padgett 2021-08-11 13:43:47 UTC
We recommend the operator either mark one of these resources as an internal object, which will prevent that resource from showing up under Installed Operators, or giving the resources different display names so the user knows the difference.

Comment 4 cvogt 2021-08-16 15:37:21 UTC
@spadgett would it make sense to maybe also include the group and version as sub text in both the card and the action dropdown?

Comment 5 Samuel Padgett 2021-08-23 15:46:07 UTC
Hey, Christian. Were you proposing this for all kinds or when ambiguous?

I'm not against adding group and version to the cards for all kinds. Putting it in the actions menu might get cluttered if we always add it.

In this particular case, is there a particular group the user should prefer? If so, we could mark the other as internal. Otherwise, it feels like there should be something in the descriptions explaining the difference and why you'd prefer one or the other. Just knowing the API group, I'm not sure I would tell which to use unless I was already knew service bindings well.

Comment 6 cvogt 2021-08-23 17:39:49 UTC
Looks like the app services team will be updating the name of the CRDs.

Comment 7 jhusta 2021-08-24 16:01:01 UTC
Thanks for update along with the naming it needs to be clear what I customer should select. So some indication of difference and why they would select one over the other.

Comment 9 jhusta 2021-09-07 19:58:48 UTC
@cvogt I just received the RC build and installed the SBO. I selected the beta selection which is SBO 0.9.1. Do you know when they will include the fix for this issue as it is still the original.

Thanks

Comment 10 jhusta 2021-09-22 14:30:21 UTC
This has been updated to 0.10 in the current release candidate build. However, there are now three subscription selections beta, candidate, preview. beta looks to be the older version and candidate and preview seem to be the same. It is unclear. Otherwise the naming of the API for candidate and preview are different. beta is the old api naming. Need to verify with dev if this is what is expected.

Comment 11 jhusta 2021-09-22 15:00:50 UTC
Based on my discussion with Predrag https://coreos.slack.com/archives/CHK22LM6Y/p1632321295227400

I am going to close this defect for the fix provided on 0.10. I will open a new defect for the channel selection as that requires additional clean up.

Comment 12 jhusta 2021-09-22 15:28:10 UTC
New defect for channel clean up https://bugzilla.redhat.com/show_bug.cgi?id=2006883


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