Bug 1625751

Summary: [apb] CLI tool does not guarantee unique Service Instance ID labels
Product: OpenShift Container Platform Reporter: Dylan Murray <dymurray>
Component: Service BrokerAssignee: Dylan Murray <dymurray>
Status: CLOSED ERRATA QA Contact: Zihan Tang <zitang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.11.0CC: aos-bugs, chezhang, jiazha, jmatthew
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-04 10:40:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dylan Murray 2018-09-05 18:27:22 UTC
Description of problem:
Currently the APB CLI tool is providing arbitrary data for `_apb_service_instance_id` and `_apb_service_class_id`. This by itself is not a problem but our sample APBs are using these values to guarantee unique resource names. Because of this, it is not possible to deploy two instances of the same APB in the same namespace (for the APBs that we ship).

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

How reproducible:
100%

Steps to Reproduce:
1. Provision postgresql
2. Observe postgresql-1234 Deployment Config
3. Provision postgresql again and can't create a new deployment config

Actual results:
Second APB provision fails

Expected results:
Deployment Config name should be guaranteed unique (e.g. postgresql-1234-2313-1231***). This can be achieved using uuids

Additional info:

Comment 1 Dylan Murray 2018-09-06 13:07:28 UTC
https://github.com/automationbroker/apb/pull/128

Comment 2 Dylan Murray 2018-09-07 16:54:25 UTC
We are going to hold off on merging this PR in for 3.11.0. I am realigning the PR to 3.11.z because the proper way to solve this is to not only use uuid's to guarantee unique labels, but also keeping track of provisioned instances.

This way when two postgresqls are provisioned for example, one will be named `postgresql-xxxx-xxxx-xxxx` and the other will be `postgresql-yyyy-yyyy-yyyy`. It is important to note that this is only because of the design of the Postgresql APB which is using these labels to guarantee uniqueness. We use dummy data in the CLI tool since we do not have a concept of service instances. The proper resolution to this bug would be to pass a uuid in for the label `_apb_service_instance_id` and then store it in ~/.apb/instances.json. Then when a user types `apb bundle deprovision postgresql-apb` we can check for existing instances and the user can select between `xxxx-xxxx-xxxx` or `yyyy-yyyy-yyyy`.

Moving back to assigned.

Comment 3 John Matthews 2018-11-09 17:49:19 UTC
Realigning to 4.0.0

Comment 4 Dylan Murray 2019-01-03 19:04:31 UTC
https://github.com/automationbroker/apb/pull/128

Comment 6 Dylan Murray 2019-01-09 18:47:47 UTC
https://github.com/automationbroker/apb/pull/128

Comment 8 Zihan Tang 2019-01-10 08:40:34 UTC
Verified 
env: 
    oc v4.0.0-0.125.0
    kubernetes v1.11.0+406fc897d8
      by openshift-install v0.9.1 
apb: apb-2.0.2

step: 
1. add registry:
2. login server as normal user (cluster-admin user provison failed #bug 1613664)
3. create new project and run provison command:
$ apb bundle provision postgresql-apb -r docker -n post

provision the same apb twice succeed.
[core@ip-10-0-12-101 ~]$ oc get pod 
NAME                                                      READY     STATUS      RESTARTS   AGE
bundle-provision-da7d4c5f-80b1-4118-9f3b-795114f16a0a     0/1       Completed   0          3m
bundle-provision-e48ffa86-19b0-4cc2-ad0b-176037153e47     0/1       Completed   0          2m
postgresql-da7d4c5f-80b1-4118-9f3b-795114f16a0a-1-b49qh   1/1       Running     0          3m
postgresql-e48ffa86-19b0-4cc2-ad0b-176037153e47-1-jzr6b   1/1       Running     0          2m

Comment 11 errata-xmlrpc 2019-06-04 10:40:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0758