Hide Forgot
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:
https://github.com/automationbroker/apb/pull/128
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.
Realigning to 4.0.0
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=19672075
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
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