Unable to create Spring Cloud Data Flow service instance, error: passed maintenance_info does not match the catalog maintenance_info

Products

• VMware Tanzu Application Service

Issue/Introduction

• The Dataflow tile is successfully installed, but creation of service instances from Apps Manager or cf CLI fail.
• Errors reported during service creation indicate:
  
  CF-MaintenanceInfoConflict(10001): Service broker error: passed maintenance_info does not match the catalog maintenance_info


• Using cf commands, target the 'p-dataflow' Org and the new Space in which the new service instance is deployed, then view cf apps, you will see:
  
  

  $ cf apps
Getting apps in org p-dataflow / space ########-####-####-####-e1b9bf586563 as admin...

  name       requested state   processes   routes
dataflow   stopped           web:0/1
skipper    stopped           web:0/1
  
  

• The services associated with this app will show 'create failed' state, with the same CF-MaintenanceInfoConflict(10001) error noted above.

 

Environment

This was observed on Elastic Application Runtime version 6.0.20 with Dataflow tile version 1.14.10. The problem is not version dependent.

Cause

The Dataflow tile installs a MySQL database along with a RabbitMQ message service during application deployment. As both the RabbitMQ and MySQL services are brokered, there is a potential they will return errors if their tile manifest configuration is not updated to the cf Catalog. See the following KB article for details on the underlying cause.

 

Review the Dataflow Service instance architecture documentation for details on how Dataflow engages MySQL and RabbitMQ to request backing message and database instances. The referenced KB article details problems with broker registration in the dependent MySQL or RabbitMQ broker tiles. These might present errors that are relayed to the Dataflow broker during service instance creation. As the Dataflow broker itself isn't configured with service_catalog.maintenance_info references, the 'CF-MaintenanceInfoConflict(10001)' error returned is being relayed from either the MySQL or the RabbitMQ broker.

Resolution

Determine which dependent broker is impacted:

• During creation of a Dataflow service instance, the MySQL DB is created first, then the RabbitMQ message service is created.
• Remove RabbitMQ messaging from being created during a test dataflow creation using the following command:
  
  cf create-service p-dataflow standard dataflow-test-noRMQ -c '{"task-only": true}'


• If the service creation still fails, the problem resides in the MySQL broker. If the service creation is successful with "-c '{"task-only": true}'", the problem resides in the RabbitMQ broker.

 

Correct the problematic dependent broker:

• Use the resolution noted in KB article on either the MySQL tile deployment or the RabbitMQ tile deployment (these are the broker deployments) to correct the underlying failure:
  
  

  In order to update the maintenance_info configuration on the marketplace, there are 3 options:

  1. Run an Apply Change on the problem broker tile with the 'register-broker' errand selected. This enables access to plans in the service catalog and updates Cloud Foundry with the new metadata.
     
     
  2. Run the 'register-broker' errand manually via bosh:
     
     bosh -d DEPLOYMENT-NAME run-errand register-broker
     
     
  3. Update the broker using CF CLI"
     
     cf update-service-broker SERVICE_BROKER USERNAME PASSWORD URL

NOTE: The username, password, and URL in the above command can be gathered from the broker manifest ENV configuration. Use bosh manifest commands to gather the required details, or cf env commands to view the environment details:
     
     bosh -d <SERVICE_BROKER_DEPLOYMENT> manifest | grep -i user

cf env <SERVICE_BROKER> | grep -i user



Use the Security User returned.