search

openshift / open-service-broker-sdk

A starting point for creating service brokers implementing the Open Service Broker API
Apache License 2.0
31 stars 33 forks source link

support for creating openshift and kubernetes objects #15

Closed maleck13 closed 4 years ago

maleck13 commented 7 years ago

One of the areas I find a barrier to getting started in working against the OpenShift API is using the OpenShift client pkg in my code. It seems you need to vendor most of Kubernetes and OpenShift in order to use it. I would like to be able to create a broker that, in order to provision its services, creates objects via the OpenShift and Kubernetes API. An early attempt at something similar can be found here: https://github.com/feedhenry/negotiator (it was started before I knew about the Service Catalog and Open Broker API) but it is essentially a broker. Is there anything in this project or any plans to make working against the OpenShift API easier from a go broker?

Aside question. Would I be right in thinking that if I wanted to use this I would change the openservicebroker and controller pkg

bparees commented 7 years ago

i'd like @pmorie to weigh in, but for my part I'll say that the brokerSDK is intended to make it easy to write a broker that runs on openshift/k8s (uses openshift/k8s resources to provide the broker API endpoint and store state), but it is not intended to specifically create brokers that provision/bind openshift/k8s resources.

In other words, the brokerSDK doesn't care if you're writing a broker that provisions ec2 instances, sends emails, stands up DBs, deploys pods in a k8s cluster, etc... the nature of the service being provisioned is irrelevant. So if we were to say "let's add help for making client requests to openshift/k8s" one could also argue we should "add help for making AWS client requests" or "add help for sending emails".

Aside question. Would I be right in thinking that if I wanted to use this I would change the openservicebroker and controller pkg

depends on exactly what you want to do, but the main areas i'd expect people to customize are:

1) the openservicebroker operations files (logic for how to handle a provision/bind/unbind/etc request) 2) the controller (this is where your logic for what to actually do on a provision request goes, because the provision operation in (1) just creates a provision request object, and the controller is responsible for seeing the request and processing it 3) the apis/broker resources as these are the resources that "store state" for your broker.

maleck13 commented 7 years ago

@bparees Thanks for the feedback. I understand where you are coming from here and agree. It makes sense that making the client easier to consume is outside the scope of this project. That said, I believe it could be a common use case to want to create/delete Objects against the OpenShift and Kubernetes API in response to a broker request? An example of how to do this would go a long way to on boarding/encouraging developers to create these kind of brokers. In the coming weeks I will use this sdk and attempt to create a broker that uses the OpenShift and Kubernetes API in order to manage the services. Would that be useful to this project as a reference?

bparees commented 7 years ago

That said, I believe it could be a common use case to want to create/delete Objects against the OpenShift and Kubernetes API in response to a broker request?

the SDK already does this, it creates a ServiceInstance resource object in response to a provision request (that is the 'broker state" storage use I referred to earlier). Take a look at the provision operation implementation (and the controller which watches/consumes/updates those resources). The only difference is that the client is actually pointing to itself as the api server, rather than the master api server.

In the coming weeks I will use this sdk and attempt to create a broker that uses the OpenShift and Kubernetes API in order to manage the services. Would that be useful to this project as a reference?

absolutely, and we'd love any PRs that can make the common parts of the SDK better as you go through the process.

openshift-bot commented 4 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 4 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

openshift-bot commented 4 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci-robot commented 4 years ago

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/open-service-broker-sdk/issues/15#issuecomment-706452034): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.