I think there might be a bug in the documentation for deprovision.

Deprovision doc states that the expected request should look like the following:

http://username:password@broker-url/v2/service_instances/:instance_id?service_id=service-id-here&plan_id=plan-id-here

However, a broker I wrote is failing on deprovision and the request I'm getting looks like this:

The service broker returned an invalid response for the request to http://10.244.4.5:8080/v2/service_instances/a65c39ab-32a9-4f74-8963-bacfbb0273c2. Status Code: 409 Conflict, Body: {}

Looking at the source code suggests a body should be returned.

It says here http://docs.cloudfoundry.org/services/api.html#binding "A URL to which Cloud Foundry should drain logs to for the bound application." Aside from the superfluous (second) "to" this is really not enough information to know what it's for. Does Cloud Foundry pipe the application logs (stdout etc.) from any app that is bound to this service to the indicated URL? Or is it a URL that I can use to download the logs from the application? What happens if more than one service is bound? Do you get more than one URL? How does that make sense (seems like it's related to the app not the service from the description above)? Or is it a URL I can get the stdout from the service instance itself (e.g. assuming it is a process that emits logs)?

New query parameters were added to the last_operation request in API version 2.9: service_id, plan_id, and operation. The service_id and plan_id query parameters are marked as required in the 2.9 docs.

The example curl command below the parameters table does not show these parameters in the query string, and it would be typical for newly added parameters to be optional for backward compatibility.

Are these two parameters really required?

Hi

I am using cassandra Service Cassandra bosh Service which is not managed now anymore.
i am getting issue with new bosh version

I am using bosh version: '261.4' and cf version: '267'

i am getting error

_Deploying

Director task 11384
Deprecation: Ignoring cloud config. Manifest contains 'networks' section.

Started preparing deployment > Preparing deployment

Deprecation: Please use 'templates' when specifying multiple templates for a job. 'template' for multiple templates will soon be unsupported.

. Done (00:00:00)

Error 100: Unable to render instance groups for deployment. Errors are:

• Unable to render jobs for instance group 'cassandra_broker_server'. Errors are:
  • Unable to render templates for job 'cassandra_server'. Errors are:
    • Error filling in template 'cassandra.yaml.erb' (line 10: undefined method `cluster_name' for nil:NilClass)
    • Error filling in template 'cassandra-env.sh.erb' (line 132: undefined method `max_heap_size' for nil:NilClass)
    • Error filling in template 'cassandra-topology.properties.erb' (line 18: Can't find property '["cassandra_server.topology"]')
    • Error filling in template 'log4j-server.properties.erb' (line 35: undefined method `persistent_directory' for nil:NilClass)
  • Unable to render templates for job 'cassandra_broker'. Errors are:
    • Error filling in template 'cassandra-broker-config.properties.erb' (line 3: undefined method `seeds' for nil:NilClass)

Task 11384 error

For a more detailed error report, run: bosh task 11384 --debug
command 'bosh -n --color -t https://xyz:2324 -d /tmp/bosh_manifest20170720-7-19irvv4 deploy' failed!_**

here is my sample manifest file
cassandra manifest file.txt

Its not managed now but if someone can help me out .

Thanks in advance

Hello team,

can you please specify in the docs that Azure and AWS LB are causing 502s when using the route service, the reason is because the gorouter is initiating the route service callout and is the source IP of the route service TCP connection which can’t happen if it’s load balancing back to itself.

So the LB will cause 502 timeout and will never be forwarded to the app.
Thank you.

The source code looks OK here:

https://github.com/cloudfoundry/docs-services/blob/master/access-control.html.md#disable-access-to-service-plans

But it isn't rendered properly (no paragraph between bulelts):

http://docs.cloudfoundry.org/services/access-control.html#enable-access

What is the somethingsecure used for in the creation of the service broker? $ cf create-service-broker mybrokername someuser somethingsecure https://mybroker.example.com/ --space-scoped

Why would i enter a password in plain text in my terminal?

When would anyone use this password again?

The project formerly known as Spring Boot CF Service Broker has been re-branded and moved. It is now Spring Cloud - Cloud Foundry Service Broker and lives at https://github.com/spring-cloud/spring-cloud-cloudfoundry-service-broker.

The sample app for this project is in the process of being moved from https://github.com/spgreenberg/spring-boot-cf-service-broker-mongo to https://github.com/spring-cloud-samples/cloudfoundry-mongodb-service-broker.

The links here should be changed to reflect these changes: https://github.com/cloudfoundry/docs-services/blob/master/examples.html.md.erb#L16

With the introduction of what I would call "private" brokers, the "Managing Brokers" page was updated in an attempt to differentiate between admin-managed brokers and user-managed brokers. The terms "Standard Private Broker" and "Space-scoped private brokers" are unnecessarily confusing. The only value in calling a broker private is when referring to user-managed, or space-scoped brokers. There's no need to say that "standard" brokers are "private" also; if all the brokers are private then this term is meaningless, because there are no public brokers. I always referred to these as "private brokers"; if they're managed by users then they're private, otherwise they're managed by the operator.

Proposed alternatives terms to differentiate these concepts:

• standard brokers vs space-scoped brokers
• operator-managed brokers vs user-managed brokers
• standard broker vs private broker

Not sure why, but if you look at the response body example on the web (https://docs.cloudfoundry.org/services/api.html#provisioning), dashboard_url is mistakenly printed as dashboardurl. The url part is italicised, so I'm guessing that the underscores are being interpreted as markdown.

This doesn't happen to the other examples. Maybe it needs two spaces at the start of the line?

https://docs.cloudfoundry.org/services/binding-credentials.html in Safari shows at the top:

Page last updated: 3 de marzo de 5877521, -8:-31:-23 GMT-7:52:58 NaN, NaN

Locale is "es-US", Safari Versión 9.0.3 (11601.4.4)

It says here: https://github.com/cloudfoundry/docs-services/blob/master/api.html.md.erb#L547 "We have chosen to require empty JSON in the response", but then there is an example response which is not empty.

I'm writing a custom V2 service broker, and what to be standards compliant.

But with GET /v2/catalog for example: id is mentioned 3 times, name twice and description twice. Please review the docs and dedupe!

https://github.com/cloudfoundry/docs-services/blob/f92440d3ae48c3b1561f4f6968e53967737dd2b9/api.html.md.erb

Hello, it's a bit difficult to read this diagram:
https://github.com/cloudfoundry/docs-services/blob/master/images/managed-services.png

It appears on this page:
https://docs.cloudfoundry.org/services/overview.html

Would it be possible to upload a high resolution version?

Thanks

In this image (http://docs.cloudfoundry.org/services/images/v2services-new.png), I guess "cf add-service-broker" should be "cf create-service-broker" now.

@SocalNick @tedsuo @dieucao

The broker API changelog was introduced to provide documentation to broker authors about when new versions were introduced, what changed in each version (this is also documented in the version specific docs), and what changes were made to the docs that did not impact the api spec. For example, we used to get questions that made us realize our docs were wrong, or required clarification. If a broker author revisits the docs and sees that the content has changed without a version bump, the changelog explains that this change occurred.

The last entry in the changelog is 2015-11-08, when 2.8 of the spec was released. There have been two versions since then. It appears the changelog is not being maintained. I would suggest CAPI commit to keeping it updated, add an entry declaring deprecation, or remove it.

I understand the merged PRs cloudfoundry/cloud_controller_ng#611 and cloudfoundry/cloud_controller_ng#592 added new "operation" parameters to provision, update and unprovision endpoints, according to the following design proposal

However, I don't see the associated specification updated in the docs-services repo (in change log or fields added)

The /v2/catalog response service object has a max_db_per_node field but it does not have any accompanying documentation.

What is this property?

The service broker API docs show the accepts_incomplete flag being passed in the body of provision and update requests, but the flag is actually passed as a request parameter to these API endpoints (as it is to the deprovision endpoint).

https://github.com/cloudfoundry/docs-services/blob/master/api.html.md.erb#L479-L483
https://github.com/cloudfoundry/docs-services/blob/master/api.html.md.erb#L649-L653

1001!

Diego appears to be required to use route services, but this isn't mentioned in the docs at http://docs.cloudfoundry.org/services/route-services.html. This would be a useful point to include.

By the way, here's the error message on attempting to bind a route service without diego:

FAILED
Server error, status code: 400, error code: 60020, message: Route services are only supported for apps on Diego. Unbind the service instance from the route or enable Diego for the app.

On http://docs.cloudfoundry.org/services/api.html it seems the latest docs refactoring omitted the convenient table of content that allowed easy discovery of the anchors permalinks

Would it be easy to restore ?

Thanks in advance,

Guillaume.

The Enabling Route Services in CloudFoundry section provides a link to the GoRouter spec. This link is no longer correct, so results in a 404 page.

Your example shows

VCAP_SERVICES=
{
cleardb: [
{
name: "cleardb-1",
label: "cleardb",
plan: "spark",
credentials: {
name: "ad_c6f4446532610ab",
hostname: "us-cdbr-east-03.cleardb.com",
port: "3306",
username: "b5d435f40dd2b2",
password: "ebfc00ac",
uri: "mysql://b5d435f40dd2b2:[email protected]:3306/ad_c6f4446532610ab",
jdbcUrl: "jdbc:mysql://b5d435f40dd2b2:[email protected]:3306/ad_c6f4446532610ab"
}
}
]

How can I encrypt user name and password do that data values will not be exposed?

Go to https://docs.cloudfoundry.org/services/api.html
The links under Table of Contents do not work, which makes it inconvenient to navigate to a particular section.
I use Google Chrome Version 57.0.2987.133 (64-bit) on Mac OSX 10.12.4.

According to the following purge-service guide, if I want to remove a service broker without first deleting the service instances binded to it, I should use the -p option.

https://docs.pivotal.io/pivotalcf/2-3/services/managing-service-brokers.html#purge-service

However in PCF if I try to remove the service broker with -p I got an warning message like below.

cf purge-service-offering my-service -p my-service

FAILED
Option '-p' only works up to CF API version 2.46.0. Your target is 2.94.0.

Instead if I just ignore the -p option it would work.

cf purge-service-offering my-service
WARNING: This operation assumes that the service broker responsible for this service offering is no longer available, and all service instances have been deleted, leaving orphan records in Cloud Foundry's database. All knowledge of the service will be removed from Cloud Foundry, including service instances and service bindings. No attempt will be made to contact the service broker; running this command without destroying the service broker will cause orphan service instances. After running this command you may want to run either delete-service-auth-token or delete-service-broker to complete the cleanup.

Really purge service offering aws-rds-aurora from Cloud Foundry?> n

Please update the doc (and other PAS that is using CAPI 2.46.0+) with correct information.

It should be made clear in the documentation that a service name must be unique, similarly to the id of the service. This is ultimately required by the CCDB services' table indices.

As a reference, here is the description for the service id:

An identifier used to correlate this service in future requests to the catalog. This must be unique within Cloud Foundry, using a GUID is recommended.