Admin permission needed to add a Service Broker - why?

46 views
Skip to first unread message

garyfr...@gmail.com

unread,
Nov 13, 2014, 11:53:31 PM11/13/14
to vcap...@cloudfoundry.org
OK, you need to be logged in as an admin to add a ServiceBroker - the question is why is this needed?    Can adding a new broker break something that affects other services or ???

Here's the scenario.   We have an application that provides a logical service for other apps (in this case a content mgmt service).   That app uses some other services for its actual data storage - so it properly runs stateless as an application.    Now, I need a service broker (either as part of the app or separate).    Then a number of content mgmt solution applications can be built against this new service...

So, why would that require me to be an admin for CF?   That prevents someone who isnt the admin of a system from even trying out scenarios like this.    Yes, someone could build a proxy/connector (sort of like what AppDirect does for PWS), but ???

Seems like a similar scenario could occur when creating a broker for an external service/database system that is already out there (especially in an enterprise setting) - a connection to Oracle or SAP or ...  Again, why would you need a CF administrator to allow usage of these external services?

Yes, you could post a URL somewhere and hand-craft code to connect to it - but everything else in CF is built around the notion of apps binding to services (through service brokers and catalogs).

So, I suspect that there is a very good reason to require admin permission, but it isnt obvious to me what it is - and I cant really find an explanation out there for the reason...

Thanks in advance for an explanation and why it would matter in these use cases.

- Gary

Ken Krueger

unread,
Nov 14, 2014, 9:27:23 AM11/14/14
to vcap...@cloudfoundry.org
+1

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/5c616111-34a8-4049-a473-020d9f594dab%40cloudfoundry.org.

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



--
Ken Krueger  
Manager, Global Education Delivery
407 256 9737 Mobile
kenkrueger65 Skype

Education questions?  educ...@pivotal.io

Shannon Coen

unread,
Nov 17, 2014, 7:21:44 PM11/17/14
to vcap...@cloudfoundry.org
Hello,

Our initial implementation of service broker management was as an admin function. We solved for the most basic use cases first, enabling an admin to manage what services appear in the public marketplace of a multi-tenant Cloud Foundry deployment. To be clear, the use case you have described has not been excluded by design; it is one I've heard before and I recognize as valuable (discussed on this list once before). Due to our iterative and rigorous approach to prioritization, we simply haven't implemented the feature yet.

I will describe what I have in mind for the feature, when we are able to prioritize it. Please let me know if this would fulfill your use case. I appreciate the feedback and will certainly note your request as this provides evidence for our prioritization.

I imagine a developer with the SpaceDeveloper role who would like to use the Services Marketplace and service create and bind operations to deliver the location and/or credentials of services which may or may not be running as applications on Cloud Foundry. The location and deployment method of both the service broker and the services it advertises are irrelevant. Once the broker API has been implemented, the developer should be able to use the same broker management CLI commands as are currently only enabled for admins. On registering the broker, the services advertised by the broker would only be visible in the Services Marketplace to users targeting a particular space or potentially any space of a particular organization. Services of user managed brokers would not be available to users of all spaces and orgs (we call these "public), as public access management would remain an admin function. Promotion of services of user managed brokers to public availability would be an independent set of features. I'd like to eventually provide mechanisms for a developer to submit their service broker for public availability, and enable an admin to configure under what circumstances this is permitted.

Best,
Shannon



garyfr...@gmail.com

unread,
Nov 18, 2014, 4:12:29 PM11/18/14
to vcap...@cloudfoundry.org, paul....@emc.com
Shannon

Thanks for  the info - what you folks have done makes sense in terms of history/prioritization...

I like your notion of exposing the Broker to the org/space without admin permissions....    At least for our use case where we would run both our service and the broker inside a given org in any case, it makes good sense...  And yes, if the enterprise cloud admins want to make it "public", that's fine.  But your suggested approach would allow developers (and even orgs) to try out safely our service without requiring admin involvement or making it generally public.   I like it.   

- Gary

Oliver Wolf

unread,
Nov 19, 2014, 6:06:28 AM11/19/14
to vcap...@cloudfoundry.org, garyfr...@gmail.com
+1
Reply all
Reply to author
Forward
0 new messages