mysql config changes will trigger re-creating the plans and changes the plan guid which screws up the mysql service instance.

[nshrest3]

Thanks for submitting an issue to pcf-pipelines. To help us triage the issue, please fill out the following form as much as you can:

Issue

I am currently using vSphere | v23.1 version of pcf-pipeline and noticed that whenever any changes happened to p-mysql tile, this will try to recreate a plan and changes its guid. This will leave the mysql service to be unusable.

Context

i see the logs during the apply-updates as

===== 2018-05-21 22:15:20 UTC Running "/usr/local/bin/bosh --no-color --non-interactive --tty --environment=10.1.192.11 --deployment=p-mysql-49b20524fb6c97cfad4a deploy /var/tempest/workspaces/default/deployments/p-mysql-49b20524fb6c97cfad4a.yml"
Using environment '10.1.192.11' as client 'ops_manager'

Using deployment 'p-mysql-49b20524fb6c97cfad4a'

  - name: cf-mysql-broker
    properties:
      cf_mysql:
        broker:
          services:
          - name: "<redacted>"
            plans:
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
  - name: broker-registrar
    properties:
      cf_mysql:
        broker:
          services:
          - name: "<redacted>"
            plans:
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>"
            - name: "<redacted>"
-             guid: "<redacted>"
+             guid: "<redacted>


Task 10486 | 22:20:54 | Running errand: broker-registrar/67285f6f-7d17-461a-bd7f-79a289b9e5bd (0) (00:00:02)
Task 10486 | 22:20:56 | Fetching logs for broker-registrar/67285f6f-7d17-461a-bd7f-79a289b9e5bd (0): Finding and packing log files (00:00:01)

Task 10486 Started  Mon May 21 22:18:55 UTC 2018
Task 10486 Finished Mon May 21 22:20:57 UTC 2018
Task 10486 Duration 00:02:02
Task 10486 done

Instance   broker-registrar/67285f6f-7d17-461a-bd7f-79a289b9e5bd  
Exit Code  1  
Stdout     CF_API_URL=https://api.sys.example.com  
           CF_SKIP_SSL_VALIDATION=false  
           CF_ADMIN_USERNAME=admin  
           BROKER_NAME=p-mysql  
           BROKER_URL=https://p-mysql.sys.example.com:443  
           BROKER_USERNAME=BLr3_XFLMt3DEoLrx1u  
           Setting api endpoint to [36;1mhttps://api.sys.example.com[0m...  
           [32;1mOK[0m  
             
           api endpoint:   https://api.sys.example.com  
           api version:    2.98.0  
           Not logged in. Use 'cf login' to log in.  
           API endpoint: [36;1mhttps://api.sys.example.com[0m  
           Authenticating...  
           [32;1mOK[0m  
           Use '[36;1mcf target[0m' to view or set your target org and space.  
           Service broker does not exist - creating broker  
           Creating service broker p-mysql as admin...  
           FAILED  
           Server error, status code: 400, error code: 270003, message: The service broker url is taken: https://p-mysql.sys.example.com:443  
           Service broker already exists - updating broker  
           Updating service broker p-mysql as admin...  
           FAILED  
           Server error, status code: 502, error code: 270012, message: Service broker catalog is invalid: Plan names must be unique within a service. Service p-mysql already has a plan named 100mb  
             

Now creating service instance for p-mysql service errors out

Server error, status code: 502, error code: 10001, message: Service broker error: Cannot create a service instance. Plan 0ac7338d-1f85-4e99-93b9-f169a838bcce was not found in the catalog.

Expected result

if any plans already exists with the same name and properties it shouldnot try to modify or recreate those plans and change the guid.

Current result

Every time the config changes happen to mysql tile it tries to create existing plan with different guid.

Steps to Reproduce

Change small configurations in p-mysql tile and run configure product and apply changes will then see new plans getting created and fails. Now no more creating mysql service works.

Possible Fix

Checks needed if no chages on plan properties, no need to create those plans (atleast preserve the old-guid so that catalog about the plans works just fine.)

Logs and Screenshots

Logs pasted in context

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.