Bug 1625751 - [apb] CLI tool does not guarantee unique Service Instance ID labels
Summary: [apb] CLI tool does not guarantee unique Service Instance ID labels
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.1.0
Assignee: Dylan Murray
QA Contact: Zihan Tang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-05 18:27 UTC by Dylan Murray
Modified: 2019-06-04 10:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:40:34 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:40:43 UTC

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


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