The project is a basic no-op cloudfoundry service gateway. You can
provision and bind to it, and the app you bind to will get some
credentials in VCAP_SERVICES
, but otherwise it doesn't do anything.
To register with the cloud controller you need to provide a config file (the default has some values in it, but won't have the right values for your environment). Then you can try and launch with, for instance
$ bin/gateway -c config/dev.yml
Note that the services base code will require /var/vcap/sys/run/LOCK
to be writable. This is fixed in the dsyer
fork so that the lock
file location can be overridden with an environment variable:
$ LOCK_FILE=/tmp/LOCK bin/gateway -c config/dev.yml
NATS registration happens before contacting the Cloud Controller so if
you have problems connecting you are hosed, but you can disable it by
not providing an mbus
entry in the local config.
The cloud controller has to be expecting us as well, so you need this
in cloud_controller.yml
the first time you run the gateway (but not
subsequently):
builtin_services:
test: 0xdeadbeef
In a BOSH deployment you can do this by adding a snippet to the
manifest and then doing a bosh deploy
:
external_service_tokens:
test: 0xdeadbeef
(Except there's a bug in the cloud_controller
job where the template
doesn't expand the external service tokens into a hash before
iterating on them.)
The cloud controller will register the service, but you need it to be registered wit the "core" provider, so don't specify that property in the gateway config file.
The Cloud Controller database doesn't seem to get updated with the new port if you change the gateweay, and the default is to pick an ephemeral port. So it's best to fix the port in the gateway YML config.
The marketplace features don't quite seem to work with the old
cloud_controller
. It's alternative way to get a service registered
in the cloud_controller
database, where the provider of the service
is not "core".
The cloud controller has to be expecting us as well, so you need this
in cloud_controller.yml
the first time you run the gateway (but not
subsequently):
service_proxy:
token: [0xdeadbeef]
where the token array contains the token value in the gateway
config. In a BOSH deployment you can do this by adding a snippet to
the manifest and then doing a bosh deploy
:
marketplace_gateway:
tokens: [0xdeadbeef]
You need to launch the gateway from a machine that can be contacted by
the cloud controller, either by automatically discovering its IP, or
by explicitly adding an ip_route
to the gateway config.
The cloud controller will register the service, but it will screw it
up and register it with provider=core
unless you explicitly give it
a provider (not equal to "core"). If it does that it can't find it
again because it always replaces "core" with nil
before querying for
the service. Here's a test:
$ jcurl -H "Content-Type: application/json" -H "X-VCAP-Service-Token: 0xdeadbeef" api.cf84.dev.las01.vcsops.com/services/v1/offerings/test-1.0/test
Note the further awkwardness of having to specify a content type for a GET (if you don't you get a 400 response).
VMC will not send the "provider" field in the service creation call. You can do it with curl:
$ jjcurl -v -H "Authorization: bearer $TOKEN" api.cf84.dev.las01.vcsops.com/services -X POST -d '{"type":"generic","vendor":"test","version":"1.0","tier":"free","name":"test","provider":"test"}'
or you can try and stick with core services, which might mean hacking the database.