FAQ
Thanks for the detailed explanation.
So the idea is to have a dedicated instance per service?
Isn't this the opposit of what cloud foundry tries to do?.
Maybe there are some usecases in which cloudfoundry is used to horizontally
scale 1 application which has to handle a big load.
I could see why you would want to use this approach. But this tool would
than also need to support clustering of the service.
However for the plugin aproach would not be usefull in a multi tenant setup.

I'm also not yet sure of the create a bosh plugin for every thing approach.
It feels really limited in its use. By adding an extra layer of complexity
you scare of potential contributors.
Also manifests are really deployment specific and there for not a good
candidate for automation.

Its however great that you are experimenting with services because they
definitely need some love.
Now that pivotal has gone the closed source marketplace route.

Kind regards,

Ruben
On Tuesday, July 9, 2013 6:02:56 PM UTC+2, Dr Nic Williams wrote:

Good question Ruben.

Ultimately I want to use the services API again. I decided to release the
bosh part of it asap.

Perhaps a service gateway could do the job that this plugin does - to
provision a service, delete a service and change a service (no API for this
at the moment afaik).

I wanted to experiment with pushing behaviour down towards bosh (it has
scaling and disk management and snapshots and backups).

I also wanted to experiment with how to make a bosh release easier to
consume (redis-boshrelease).

I also wanted to try out the "bosh diff" temp laying system; and is what
it's pros/cons are compared to building up a hash and to_yaml'ing it (like
I did in bosh-cloudfoundry).

I don't understand warden yet, how to debug it, and how it's being wielded
by vcap-services-base.

I am uncomfortable with over investing my time (and clients' money) in the
existing services that Pivotal (the main investor in contributions to CF
and the only people with commit access) have recently executed their
promise to "un-support".

They have started internal discussions on a v3 API. From chats with them,
their plans for v3 services do not go into the realms of functionality that
I think are necessary (using bosh as part of the service; not just to
deploy the running pieces), so I wanted to start experimenting towards the
services UX that I think we need (something user facing like Heroku
Postgres).

I also want to keep the implementation of the core service (Redis in this
case) isolated from the orchestration and management (the bosh plugin). I
found it very hard to understand the relationships between
vcap-services-base, cf-services-release, warden and the actual postgresql
service itself. I could not just drop it all into cf-vagrant-installer and
develop on it. It was all tangled up together.

Finally, I just needed to get a Redis UX that worked for a client asap.
They can't run apps on their shiny CF deployment that need Redis if there
isn't a way to get Redis. So I first deployed Redis-boshrelease manually;
then wrote this nice bosh plugin to simplify it over the weekend.

Next I might wrote another plugin to simplify cf-release v2 to replace
bosh-cloudfoundry (and hopefully the AWS-VPC-only one-size only
bootstrapper we have now). Oooh yeah.
--
Dr Nic Williams
Stark & Wayne LLC - the consultancy for Cloud Foundry
http://starkandwayne.com
+1 415 860 2185
twitter: drnic


On Tue, Jul 9, 2013 at 6:47 AM, ruben....@innovationfactory.eu<javascript:>
<ruben....@innovationfactory.eu <javascript:>> wrote:
why not use services for this?
On Monday, July 8, 2013 9:38:20 PM UTC+2, Dr Nic Williams wrote:

If you try this out and dig around the code, you'll notice there is no
"git clone" for the redis bosh release. All the bits necessary to upload
the bosh release are stored in the rubygem that you download above.

On Mon, Jul 8, 2013 at 12:15 PM, Dr Nic Williams wrote:

I need a simple way to create and delete (and ultimate upgrade)
dedicate services - redis, postgresql, etc. In this post I introduce a
simple CLI for creating a Redis server, getting the URI for the service,
binding it to your Cloud Foundry app, and later deleting it.

Here is an example scenario for installing the plugin, login to bosh
(ask your sysadmin for credentials), uploading the redis release to bosh,
and then creating and deleting as many redis servers as you and your team
need.

$ gem install bosh_cli "~> 1.5.0.pre" --source https://s3.amazonaws.com/bosh-jenkins-gems/ $ gem install bosh_cli_plugin_redis
$ bosh prepare redis$ bosh create redis$ bosh show redis uri
redis://:c1da049a75b3@0.redis.default.demoredis.microbosh:6379/0$ cf set-env myapp REDIS_URI redis://:c1da049a75b3@0.redis.default.redis-123.microbosh:6379/0
$ cf unset-env myapp REDIS_URI$ bosh delete redis


The blog post with known limitations & how-tos is at
http://starkandwayne.com/articles/2013/07/08/simple-redis-service/

The source for the CLI plugin is at
https://github.com/drnic/bosh_cli_plugin_redis

The source for running redis upon bosh is
https://github.com/cloudfoundry-community/redis-boshrelease


Does this UX seem nice to you?


--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic


--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic
------------------------------

Have an innovative day

*Innovation Factory *De Lairessestraat 180* *1075 HM Amsterdam* *+31
20 7787008 www.innovationfactory.eu

*
Disclaimer*
*The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited. If you received this in error, please contact the sender and
delete the material from any computer. Innovation Factory does not accept
liability for any errors, viruses or omissions in the contents of this
message, which may arise as a result of e-mail transmission. No employee or
agent is authorized to conclude any binding agreement on behalf of
Innovation Factory with another party by email.*
--

------------------------------

Have an innovative day

*Innovation Factory *De Lairessestraat 180* *1075 HM Amsterdam* *+31
20 7787008 www.innovationfactory.eu

*
Disclaimer*
*The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited. If you received this in error, please contact the sender and
delete the material from any computer. Innovation Factory does not accept
liability for any errors, viruses or omissions in the contents of this
message, which may arise as a result of e-mail transmission. No employee or
agent is authorized to conclude any binding agreement on behalf of
Innovation Factory with another party by email.*

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 5 | next ›
Discussion Overview
groupbosh-users @
postedJul 8, '13 at 7:15p
activeJul 11, '13 at 4:02p
posts5
users2

2 users in discussion

Dr Nic Williams: 3 posts Ruben Koster: 2 posts

People

Translate

site design / logo © 2021 Grokbase