|Number of watchers on Github||56|
|Number of open issues||14|
|Average time to close an issue||18 days|
|Average time to merge a PR||12 days|
|Open pull requests||12+|
|Closed pull requests||28+|
|Last commit||over 1 year ago|
|Repo Created||about 6 years ago|
|Repo Last Updated||over 1 year ago|
|Organization / Author||cloudfoundry|
|Do you use cf-mysql-release? Leave a review!|
|View open issues (14)|
|View cf-mysql-release activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Trendy new open source projects in your inbox! View examples
|CF MySQL Broker||Advertises the MySQL service and plans. Creates and deletes MySQL databases and credentials (bindings) at the request of Cloud Foundry's Cloud Controller.|
|MySQL Server||The MySQL instances, either single or 3-node cluster. Currently using MariaDB 10 (versions vary by release).|
|Proxy||Switchboard; proxies to MySQL, severing connections on MySQL node failure.|
Traffic to the MySQL cluster is routed through one or more proxy nodes. The current proxy implementation is Switchboard. This proxy acts as an intermediary between the client and the MySQL server, providing failover between MySQL nodes. The number of nodes is configured by the proxy job instance count in the deployment manifest.
NOTE: If the number of proxy nodes is set to zero, apps will be bound to the IP address of the first MySQL node in the cluster. If that IP address should change for any reason (e.g. loss of a VM) or a proxy was subsequently added, one would need to re-bind all apps to the IP address of the new node.
For more details see the proxy documentation.
A user-facing service dashboard is provided by the service broker that displays storage utilization information for each service instance.
The dashboard is accessible by users via Single Sign-On (SSO) once authenticated with Cloud Foundry.
The dashboard URL can be found by running
cf service MY_SERVICE_INSTANCE.
Service authors interested in implementing a service dashboard accessible via SSO can follow documentation for Dashboard SSO.
SSO is initiated when a user navigates to the URL found in the
dashboard_url field. This value is returned to cloud controller by the broker in response to a provision request, and is exposed in the cloud controller API for the service instance. A users client must expose this field as a link, or it can be obtained via curl (
cf curl /v2/service_instances/:guid) and copied into a browser.
SSO requires the following OAuth client to be configured in cf-release. This client is responsible for creating the OAuth client for the MySQL dashboard. Without this client configured in cf-release, the MySQL dashboard will not be accessible but the service will be otherwise functional. Registering the broker will display a warning to this effect.
properties: uaa: clients: cc-service-dashboards: secret: cc-broker-secret scope: cloud_controller.write,openid,cloud_controller.read,cloud_controller_service_permissions.read authorities: clients.read,clients.write,clients.admin authorized-grant-types: client_credentials
SSO was implemented in v169 of cf-release; if you are on an older version of cf-release you'll encounter an error when you register the service broker. If upgrading cf-release is not an option, try removing the following lines from the cf-mysql-release manifest and redeploy.
dashboard_client: id: p-mysql secret: yoursecret
The following links show how this release implements Dashboard SSO integration.
The dashboard URL defaults to using the
https scheme. This means any requests using
http will automatically be redirected to
To override this, you can change
Keep in mind that changing the
ssl_enabled setting for an existing broker will not update previously advertised dashboard URLs.
Visiting the old URL may fail if you are using the SSO integration,
because the OAuth2 client registered with UAA will expect users to both come from and return to a URI using the scheme
implied by the
https, the broker must be reached through an SSL termination proxy.
Connecting to the broker directly on
https will result in a
port 443: Connection refused error.
By default, the broker will not trust a self-signed SSL certificate when communicating with cf-release.
To trust self-signed SSL certificates, you can change
Stable releases, also known as final releases, are available for general use. Release notes and source code are available on github. Instructions for uploading a final release to your BOSH director can be found on bosh.io.
Note: If your BOSH director's able to access the Internet, you don't need to download and upload a release to your BOSH director. When using cf-mysql-deployment, the correct release is referenced in the manifest, and will be automatically retrieved by the BOSH director.
See our contributing docs for instructions on how to make a pull request.
This BOSH release doubles as a
$GOPATH. It will automatically be set up for
you if you have direnv installed.
# fetch release repo mkdir -p ~/workspace cd ~/workspace git clone https://github.com/cloudfoundry/cf-mysql-release.git cd cf-mysql-release/ # switch to develop branch (not master!) git checkout develop # automate $GOPATH and $PATH setup direnv allow # initialize and sync submodules ./scripts/update
If you do not wish to use direnv, you can simply
.envrc file in the root
of the release repo. You may manually need to update your
as you switch in and out of the directory.
For more information, check out the documentation.
See https://github.com/cloudfoundry/cf-mysql-deployment to deploy cf-mysql release.
download-logs, including now relying on
bosh sshrather than having manual SSH set up independently.
Dependency Updates and Bug Fixes
We discovered that in switching over to syslog-release, we hadn't fully stopped independently sending logs to syslog. We've pared that back.
When a MySQL server VM disappears, BOSH will recreate that VM with the same IP address. When that new VM does not share the same ethernet MAC address as the old one, switchboard will not be able to direct connections to the new VM.
BOSH has a feature to clear the old ethernet address from switchboard's cache, but this feature used to default to
off. For this reason, switchboard contained a duplicate feature to ensure that it is able to reach the new VM.
Recently, we discovered that this code does not work when BOSH DNS is enabled. This bug has been fixed, see below. However, in doing, we've learned that the switchboard feature does not work on GCP, and possibly other IaaSes.
The BOSH feature is designed to work on any IaaS that BOSH supports. In a coming release, we will drop the duplicate switchboard feature.
We strongly suggest that you run all of your Directors with flush-arp enabled. If you do not have flush-arp enabled, you may encounter issues where switchboard is not able to reach a back end node, even after successful resurrection.
Breaking Change: We've cut independent calls to syslog from
cf-mysql-release and now depend on syslog-release to do that work for us. If you are using cf-mysql-deployment, simply use the enable-syslog.yml operations file, and provide the following variables:
Deploying with the
enable-syslog.yml operations file will affect only the
cf-mysql deployment. You don't need to use it if you already use
syslog-release as a BOSH add-on.
In #144637793, we introduced the new property,
cf_mysql.mysql.enable_local_file and set the default to
false. This is inconvenient, because it affects commonly used tools such as
mysqlimport. The property is still there, but we've switched the default to
cf_mysql.mysql.long_query_time, which you can set to the minumum number of seconds a query must run before showing up in the slow query log.
The focus of this release is to catch up on a few items that didn't make v36.8.0.
Execution Failedstate when taking time to start [#152650758]
cf-mysql-releaseis used by
cf-deployment. This paranoid option is still available, we're just changing the default to
As always, please refer to cf-mysql-deployment for deployment instructions, manifest and sample overrides files.