Deploying services for the first time

[brando...@newwave-technologies.com]

Hi all,
I've deployed CF v142 in my Open Stack dev environment, and I'm trying to deploy a test service. I've followed all of the directions found here: http://docs.cloudfoundry.com/docs/running/deploying-cf/adding-services.html. Reaching the end, I am greeted with the below error.

http://paste.openstack.org/show/47782/

As it doesn't seem to originate from any component of CF, I don't really know how to address the error. Any help would be appreciated. I've also pasted the services manifest below.

http://paste.openstack.org/show/47783/

Brandon

[Dr Nic Williams]

Did you run "cf create-service-auth-token" to set that up?

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[brando...@newwave-technologies.com]

I did, I have the token. I followed the directions exactly.

[Dr Nic Williams]

I think v142 may have a service gateway regression that Ruben discovered (see vcap-service-base issues I think).

I am under sure of the resolution. Perhaps all the gateways in contrib have been forced to upgrade their vcap-service-base git SHA.

Perhaps also try reverting to v141.

[Maaz Khan]

Can you provide the Postgresql gateway and node log files

 

Maaz

[Shannon Coen]

It's not clear what the problem is from the error Brandon posted because all that is returned is the totally unhelpful, generic "10001 Server Error". We're working on exposing all errors to make troubleshooting easier.

Nic, are you thinking of this issue? https://github.com/cloudfoundry/vcap-services-base/pull/15

We added the field 'type' to cloud controller service-related api responses, including endpoints called by v1 service brokers. The problem was that vcap-services-base was intolerant of additional fields. So we updated vcap-services-base to be tolerant. We believe the first version of cf-release which had this problem was 136. You could downgrade cf-release to 135, but I would instead propose that v1 service brokers are updated to use the new version of vcap-services-base in order to be compatible with cf-release v136 or later.

Our strategy for backward compatibility is that within a major version of the API:

- make additive changes only

- don't remove anything

- making required fields optional is ok, but not vice versa

Unfortunately vcap-services-base didn't support this strategy. We believe that the pain of requiring v1 brokers to upgrade to the latest vcap-services-base in order to use the cf-release v136 or later is worth enabling the above strategy without breaking v1 brokers in the future. I'd be interested in hearing from the community if you have strong feelings one way or the other on this.

Thank you,

Shannon

[Dr Nic Williams]

Shannon, it would be great to know of critical breaking changes as soon as the commits hit the various repos (e.g. ccng or vcap-services-base). Then perhaps the services can be fixed in time for the next cf-release final release. Its hard watching all commits across all projects and mentally figuring out if its going to break something. Early warning on this list would be fantastic.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Dr Nic Williams

Stark & Wayne LLC - consultancy for Cloud Foundry users

http://drnicwilliams.com

http://starkandwayne.com

cell +1 (415) 860-2185

twitter @drnic

[Shannon Coen]

I can assure you this breaking change was not intentional, and not understood until we dug into the pull request. Had we predicted it I would definitely have posted to this list with a proposal for the change and requested feedback. I did this recently regarding the Legacy API in Cloud Controller, and intend to do so in the future. 

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen