BOSH release for v2 MySQL service is now open source
178 views
Skip to first unread message
Shannon Coen
Dec 13, 2013, 2:03:32 PM12/13/13
to vcap...@cloudfoundry.org
We've open sourced the BOSH release for our v2 MySQL service.
By v2 we mean the service broker for this service (https://github.com/cloudfoundry/cf-mysql-broker) has been written for the v2 Service Broker API.
This service is very basic; it doesn't have feature parity with the v1 MySQL service. But it does provision databases and credentials, enforces storage and connection quotas, and most importantly demonstrates the v2 broker API.
With the goal of making broker development even easier, we have multiple teams in Pivotal currently developing simpler implementations of the new API in multiple languages. I hope to share these with you soon.
We are actively working to improve both the API docs and the README for this release. Please open issues or pull requests if anything isn't clear or can be improved.
Thank you,
Dr Nic Williams
Dec 13, 2013, 2:29:37 PM12/13/13
to vcap...@cloudfoundry.org, vcap...@cloudfoundry.org
Shannon and team, thanks for publishing a bosh release to go with the broker!
As a class exercise we created a Java version of the MySQL broker and now we're creating a bosh release for it, using the mysql job from your release! Exciting that it can happen so quickly.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Mike Heath
Dec 13, 2013, 3:44:46 PM12/13/13
to vcap...@cloudfoundry.org
With the goal of making broker development even easier, we have multiple teams in Pivotal currently developing simpler implementations of the new API in multiple languages. I hope to share these with you soon.
Does this include Java? I'm planning to update our open source Java service broker framework[1] soon but if Pivotal is already doing this work, maybe I'll hold off.
-Mike
Dr Nic Williams
Dec 13, 2013, 3:57:07 PM12/13/13
to vcap...@cloudfoundry.org
Mike, did your v1 sdk implement services with warden? Any work in this space to be reused for your v2 sdk?
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Mike Heath
Dec 13, 2013, 4:03:59 PM12/13/13
to vcap...@cloudfoundry.org
No. Currently we just try to make it simple to build service brokers. In our case, we have a bunch of existing enterprise services that we're integrating with. We don't do anything yet in the way of automatically provisioning databases and the like.
When we do get to the point of doing anything where Warden would make sense, we'll probably write the Warden piece in Ruby or Go and integrate with it over NATS and/or REST.
Shannon Coen
Dec 13, 2013, 5:24:18 PM12/13/13
to vcap...@cloudfoundry.org, Steve Greenberg
Hello Mike,
I recently became aware that Steve Greenberg at Pivotal has been working on a Spring-based framework for v2 broker development.
Steve says he's willing to have the project hosted in a community github org (cloudfoundry-samples, for example). Before we do that he says he'd like to finish with a Mongo implementation which has lead to a bunch of refactoring.
Take a look at what Steve is working on; maybe it provides a jumping off point, or could be leveraged/merge in updating cf-java-component?
Best,
Shannon
Mike Heath
Dec 13, 2013, 5:40:23 PM12/13/13
to vcap...@cloudfoundry.org, Steve Greenberg
Shannon,
-Mike
Shannon Coen
Dec 19, 2013, 4:59:59 PM12/19/13
to vcap...@cloudfoundry.org, Steve Greenberg
Steve has finished his refactor. Would it be valuable to the community if the repo (https://github.com/spgreenberg/cloudfoundry-service-broker) was located in a github org which was more discoverable and welcoming for contribution, like cloudfoundry-samples or cloudfoundry-community?
Thank you,
Shannon
Mike Heath
Dec 19, 2013, 6:16:42 PM12/19/13
to vcap...@cloudfoundry.org, Steve Greenberg
I would much rather see it in a more discoverable GitHub org. This would also help people realize that it's not just a personal project.
-Mike
Shannon Coen
Dec 31, 2013, 6:00:47 PM12/31/13
to vcap...@cloudfoundry.org, Steve Greenberg
We're going to move Steve's repo to a more discoverable GitHub org; likely cloudfoundry-community.
On a related note, we're wrapping up a simple example broker in Ruby (https://github.com/cloudfoundry-samples/github-service-broker-ruby) and had planned to do one in Java next. However, considering that Steve's project provides a framework/template for building v2 service brokers in Spring, and there appears to be at least one other v2 broker written in Java, I've been thinking Pivotal may not need to provide another example for Java. Do the Java developers out there feel there are sufficient examples to develop their own service brokers?
Finally, we had also considered providing an example v2 broker in Node.js but have been thinking this might be a fun project for someone from the community. Would anyone like to port our Github service or MySQL service to Node.js as an example?
Thank you,
James Bayer
Dec 31, 2013, 6:12:47 PM12/31/13
to vcap...@cloudfoundry.org, Steve Greenberg
we had also considered a python example, but aren't sure if any one really wants or needs that given the other examples.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Thank you,
James Bayer
Aristoteles Neto
Dec 31, 2013, 6:26:11 PM12/31/13
to vcap...@cloudfoundry.org
Personally, I’d love to see python example. But I just got here, so don’t take my word for it :P
Shannon Coen
Dec 31, 2013, 7:03:36 PM12/31/13
to vcap...@cloudfoundry.org
Oops, I meant python, not node.js. Thanks, James.
Shannon Coen
Jan 3, 2014, 12:11:21 PM1/3/14
to vcap...@cloudfoundry.org
Could someone with admin rights help Steve move his repo into cloudfoundry-community?
Thank you,
Shannon
Guillaume Berche
Jan 3, 2014, 12:47:34 PM1/3/14
to vcap...@cloudfoundry.org, Steve Greenberg
Thanks for the sample service brokers, this is very useful.
I'm wondering what would be the recommended way to implement a service broker that dynamically instanciates nodes as to be trutly elastic and not require manual capacity adjustments to cope with increased demand. For a CF operator, installing such service would gets the same effect as installing a "service cartridge" in other paas such as openshift. Any one has experience with such elastic services that could be shared ?
Ideally such elastic service would be able to run on both public and private CF instances.
I was thinking this service broker would dynamically instanciate nodes running as cf apps using the CC API e.g. through vcap-java. Nodes would run a custom buildpack that installs and configure the JMS server. Potentially, this buildpack could invoke puppet/chef recipes to ease the setup (sad that bosh infrastructure can't be leveraged here)
An alternative for private CF instance that was discussed a while ago was bosh dynamic pools [1] any news on this since then?
As a proof-of-concept, I was thinking of a JMS service (i.e. the service node offer JMS services to other apps).
[1] https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/jYohaSSDevQ/discussion
I'm wondering what would be the recommended way to implement a service broker that dynamically instanciates nodes as to be trutly elastic and not require manual capacity adjustments to cope with increased demand. For a CF operator, installing such service would gets the same effect as installing a "service cartridge" in other paas such as openshift. Any one has experience with such elastic services that could be shared ?
Ideally such elastic service would be able to run on both public and private CF instances.
I was thinking this service broker would dynamically instanciate nodes running as cf apps using the CC API e.g. through vcap-java. Nodes would run a custom buildpack that installs and configure the JMS server. Potentially, this buildpack could invoke puppet/chef recipes to ease the setup (sad that bosh infrastructure can't be leveraged here)
An alternative for private CF instance that was discussed a while ago was bosh dynamic pools [1] any news on this since then?
As a proof-of-concept, I was thinking of a JMS service (i.e. the service node offer JMS services to other apps).
[1] https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/jYohaSSDevQ/discussion
Dr Nic Williams
Jan 3, 2014, 12:50:22 PM1/3/14
to vcap...@cloudfoundry.org
It's done now. Shannon, what's your github ID and I'll add you too.
Nic
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Shannon Coen
Jan 3, 2014, 1:45:09 PM1/3/14
to vcap...@cloudfoundry.org
This probably deserves to be a separate thread. Nic has recently demonstrated use of BOSH by a service broker, and there are other examples of brokers pushing apps using cc API. At a high level, the broker can be a proxy or itself responsible for orchestration of instances (whether instances represent accounts, apps, nodes, clusters, or something else).
Really excited to hear the creative ways people are using brokers; looking forward hearing more!
Steve Greenberg
Jan 3, 2014, 1:50:22 PM1/3/14
to Shannon Coen, vcap...@cloudfoundry.org
The repository has been moved to the cloudfoundry-community and renamed to "spring-service-broker".
Dr Nic Williams
Jan 3, 2014, 1:51:13 PM1/3/14
to vcap...@cloudfoundry.org
Shannon, how is the async broker API work going?
Shannon Coen
Jan 3, 2014, 1:53:11 PM1/3/14
to vcap...@cloudfoundry.org
We're wrapping up internal review of a design doc. Hope to share this doc with the community sometime next week and solicit feedback.
Dr Nic Williams
Jan 3, 2014, 1:56:34 PM1/3/14
to vcap...@cloudfoundry.org
Ok, thanks.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
Reply all
Reply to author
Forward
0 new messages