Git Product home page Git Product logo

minibroker's Introduction

Build Status

Minibroker

A minibroker for your minikube!

Minibroker is an implementation of the Open Service Broker API suited for local development and testing. Rather than provisioning services from a cloud provider, Minibroker provisions services in containers on the cluster.

Minibroker uses the Kubernetes Helm Charts as its source of provisionable services.

While it can deploy any stable chart, Minibroker provides the following Service Catalog Enabled services:

  • mysql
  • postgres
  • mariadb
  • mongodb
  • redis
  • rabbitmq

Minibroker has built-in support for these charts so that the credentials are formatted in a format that Service Catalog Ready charts expect.

Prerequisites

Run the following commands to set up a cluster:

minikube start

helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
kubectl create namespace svc-cat
helm install catalog --namespace svc-cat svc-cat/catalog

Install Minibroker

helm repo add minibroker https://minibroker.blob.core.windows.net/charts
kubectl create namespace minibroker
helm install minibroker --namespace minibroker minibroker/minibroker

NOTE: Platform users provisioning service instances will be able to set arbitrary parameters, which can be potentially dangerous, e.g. if setting a high number of replicas. To prevent this, it is possible to define override parameters per service in the according fields of the provisioning chart value. If defined, the user-defined parameters are dropped and the override parameters are used instead.

Installation Options

  • Only Service Catalog Enabled services are included with Minibroker by default, to include all available charts specify --set serviceCatalogEnabledOnly=false.
  • The stable Helm chart repository is the default source for services, to change the source Helm repository, specify --set helmRepoUrl=https://example.com/custom-chart-repo/.

Update Minibroker

helm upgrade minibroker minibroker/minibroker \
  --install \
  --set deploymentStrategy="Recreate"

Usage with Cloud Foundry

The Open Service Broker API is compatible with Cloud Foundry, and minibroker can be used to respond to requests from a CF system.

Installation

CF doesn't require the Service Catalog to be installed. The Cloud Controller, which is part of the CFAR (Clouf Foundry Application Runtime), is the Platform as specified in the OSBAPI.

helm repo add minibroker https://minibroker.blob.core.windows.net/charts
kubectl create namespace minibroker
helm install minibroker minibroker/minibroker \
  --namespace minibroker \
  --set "deployServiceCatalog=false" \
  --set "defaultNamespace=minibroker"

Usage

The following usage instructions assume a successful login to the CF system, with an Org and Space available. It also assumes a CF system like KubeCF that runs in the same Kubernetes cluster as the minibroker. It should be possible to run the minibroker separately, but this would need a proper ingress setup.

cf create-service-broker minibroker user pass http://minibroker-minibroker.minibroker.svc
cf enable-service-access redis
echo > redis.json '[{ "protocol": "tcp", "destination": "10.0.0.0/8", "ports": "6379", "description": "Allow Redis traffic" }]'
cf create-security-group redis_networking redis.json
cf bind-security-group   redis_networking org space
cf create-service redis 4-0-10 redis-example-svc

The service is then available for users of the CF system.

git clone https://github.com/scf-samples/cf-redis-example-app
cd cf-redis-example-app
cf push --no-start
cf bind-service redis-example-app redis-example-svc
cf start redis-example-app

The app can then be tested to confirm it can access the Redis service.

export APP=redis-example-app.cf-dev.io
curl -X GET $APP/foo # Returns 'key not present'
curl -X PUT $APP/foo -d 'data=bar'
curl -X GET $APP/foo # Returns 'bar'

Examples

$ svcat get classes
     NAME             DESCRIPTION
+------------+---------------------------+
  mariadb      Helm Chart for mariadb
  mongodb      Helm Chart for mongodb
  mysql        Helm Chart for mysql
  postgresql   Helm Chart for postgresql

$ svcat describe class mysql
  Name:          mysql
  Description:   Helm Chart for mysql
  UUID:          mysql
  Status:        Active
  Tags:
  Broker:        minibroker

Plans:
   NAME             DESCRIPTION
+--------+--------------------------------+
  5-7-14   Fast, reliable, scalable,
           and easy to use open-source
           relational database system.

$ svcat provision mysqldb --class mysql --plan 5-7-14 -p mysqlDatabase=mydb -p mysqlUser=admin
  Name:        mysqldb
  Namespace:   minibroker
  Status:
  Class:       mysql
  Plan:        5-7-14

Parameters:
  mysqlDatabase: mydb
  mysqlUser: admin

$ svcat bind mysqldb
  Name:        mysqldb
  Namespace:   minibroker
  Status:
  Secret:      mysqldb
  Instance:    mysqldb

$ svcat describe binding mysqldb --show-secrets
  Name:        mysqldb
  Namespace:   minibroker
  Status:      Ready - Injected bind result @ 2018-04-27 03:53:09 +0000 UTC
  Secret:      mysqldb
  Instance:    mysqldb

Parameters:
  {}

Secret Data:
  database              mydb
  host                  lucky-dragon-mysql.minibroker.svc
  mysql-password        gsIpB8dBEn
  mysql-root-password   F8aBHuo8zb
  password              gsIpB8dBEn
  port                  3306
  uri                   mysql://admin:[email protected]:3306/mydb
  username              admin

$ svcat unbind mysqldb
$ svcat deprovision mysqldb

To see Minibroker in action try out our Wordpress chart, that relies on Minibroker to supply a database:

helm install minipress minibroker/wordpress

Follow the instructions output to the console to log into Wordpress.

Helm Chart Parameters

Minibroker passes parameters specified during provisioning to the underlying Helm Chart. This lets you customize the service to specify a non-root user, or the name of the database to create, etc.

Local Development

Requirements

Setup

  1. Create a Minikube cluster for local development by running make create-cluster. It defaults to using Docker as a VM driver. If you want to use a different VM driver, set the VM_DRIVER environment variable. E.g. VM_DRIVER=kvm2 make create-cluster.
  2. Point your Docker to use the Minikube Docker daemon on the current shell session by running eval $(minikube docker-env).

Deploy

Compile and deploy the broker to your local cluster by running IMAGE_PULL_POLICY="Never" make image deploy.

Test

make test

There is an example chart for Wordpress that has been tweaked to use Minibroker for the database provider, run make setup-wordpress to try it out.

minibroker's People

Contributors

aduffeck avatar bysph avatar carolynvs avatar carolynvs-msft avatar dependabot[bot] avatar evalle avatar f0rmiga avatar gberche-orange avatar hezhizhen avatar jhvhs avatar k8s-ci-robot avatar kvaps avatar mook-as avatar sebastien-prudhomme avatar ultimateboy avatar wyyxd2017 avatar zulandar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

minibroker's Issues

Broker permission error

I got the error:

controller.go:293] error getting the cluster info configmap: "configmaps \"cluster-info\" is forbidden: User \"system:serviceaccount:svc-cat:service-catalog-controller-manager\" cannot get configmaps in the namespace \"default\""

The service-catalog-controller-manager didn't have permission. It was causing a ErrorFetchingCatalog error.

I fixed it, for the moment, by giving the service account:

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

I didn't get this in other environments I've run the catalog in.

Disclaimer, I read the warning "This is still a work-in-progress, it's not usable yet." but I wanted to try anyway. Figured I'd pass this on.

`helmRepoURL` should allow multiple values

Ideally, administrators would have a way to supply URLs for multiple helm repos when installing minibroke. This will be useful in situations where the services they wish to provide aren't all in one repository.

minibroker shouldn't auto-register

I believe that minibroker assumes it's being installed into the same kube cluster that will be used by the applications of those services. I don't believe this is a safe assumption - especially when one of the main uses for svc-cat is to leverage 3rd party (external) services. Nor do I think we can assume that the scope of the broker (cluster vs namespace-scope) can be defaulted.

The helm chart for minibroker should do ONLY what people asked, which is to install minibroker in this cluster. If they then want it to be registered as a broker with this cluster's svc-cat then they can ask for it.

I found this because I was playing with this chart and could not figure out why I was seeing a broker even though I never asked for one to be installed.

I think it might be ok to add a flag to auto-register, but I don't think it should be the default. Unless the intent is for this to be ONLY for demo purpose - where there's only ever one kube cluster involved.

Delete PVCs when deprovisioning

Right now, Minibroker doesn't act on any PVCs.
The k8s rule is that it doesn't delete a PVC when the StatefulSet is deleted.
Effectively, for Minibroker, this means we are just building up PVC count.
An idea is that Minibroker would automatically delete the PVCs and, if the platform operator wants the same guarantees that the PV won't be gone, the ReclaimPolicy of the storage class can be set to Retain.
@carolynvs any thoughts?

should the minibroker run in not k8s env ?

should the minibroker run in not k8s env, but in location machine ?in other words, if the service broker implement the osb api, and want to deploy it, it must run in k8s env ?

Deprovision request while the service instance is being created doesn't have the correct behaviour

From the OBSAPI in https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#deprovisioning:

If a Service Broker accepts the request to delete a Service Instance during the process of it being provisioned, then it MUST have the net effect of halting the current creation process and beginning the deletion of any resources associated with the Service Instance.

Currently, Minibroker doesn't obey this paragraph in the spec.

Update chart repository URL to Bitnami

Issue #115 fixed the issue with the Helm "stable" repo URL move, but all of the most recent charts minibroker uses in that repo are marked as DEPRECATED by the Bitnami maintainers. It may be time to simply point to the Bitnami repo for the latest charts.

I've tested this by setting helmRepoUrl: "https://charts.bitnami.com/bitnami" and deploying the latest releases of RabbitMQ, PostgreSQL, MariaDB, MongoDB, and Redis. I have not tested MySQL, but I assume this works as well.

PostgreSQL/MariaDB provided database fails with 'FATAL: database "null" does not exist'

I'm using minbroker on kubecf, installed as follows:

helm repo add minibroker https://minibroker.blob.core.windows.net/charts 
kubectl create namespace minibroker 
helm install minibroker --namespace minibroker --set "deployServiceCatalog=false" --set "defaultNamespace=minibroker" minibroker/minibroker

My application is bound to the database with the following variables:

 "VCAP_SERVICES": {                                                                                                 
  "postgresql": [                                                                                                   
   {                                                                                                                
    "binding_name": null,                                                                                           
    "credentials": {                                                                                                
     "database": "",                                                                                                
     "host": "postgresql-4141dd8b527947166d76.minibroker.svc.cluster.local",                                        
     "password": "x",                                                                                      
     "port": 5432,                                                                                                  
     "postgresql-password": "x",                                                                           
     "protocol": "postgresql",                                                                                      
     "uri": "postgresql://postgres:[email protected]:5432",   
     "username": "postgres"                                                                                         
    },      
...                                                                                                        

Trying the same with MariaDB yields the same result:

 "VCAP_SERVICES": {                                                                                      
  "mariadb": [                                                                                           
   {                                                                                                     
    "binding_name": null,                                                                                
    "credentials": {                                                                                     
     "database": "",                                                                                     
     "host": "mariadb-5883244b3a7a4716e4c1.minibroker.svc.cluster.local",                                
     "mariadb-replication-password": "x",                                                       
     "mariadb-root-password": "x",                                                              
     "password": "x",                                                                           
     "port": 3306,                                                                                       
     "protocol": "mysql",                                                                                
     "uri": "mysql://root:[email protected]:3306",    
     "username": "root"                                                                                  
    },                                                                                                   
...

As you can see, the database attribute is empty, and that results in the error at application startup:

08:35:42.918: [APP/PROC/WEB.0] 2020-11-15 07:35:42.916  INFO 6 --- [           main] c.s.t.config.CloudDatabaseConfiguration  : Configuring JDBC datasource from a cloud provider
08:35:44.582: [APP/PROC/WEB.0] 2020-11-15 07:35:44.577 ERROR 6 --- [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Exception during pool initialization.
08:35:44.582: [APP/PROC/WEB.0] org.postgresql.util.PSQLException: FATAL: database "null" does not exist

How do I make minibroker create and provide a database when creating the service? Thanks.

ARM64/aarch64 image

Would be possible to have an image for the ARM64/aarch64 arch? service-catalog has support for it with the image https://quay.io/repository/kubernetes-service-catalog/service-catalog-arm64?tag=v0.3.1&tab=tags, it would be nice if you could also add the ARM target.

Thanks.

Update CI for minibroker

  1. The push to docker hub is broken because I had to rotate my creds due to the great docker breach of 2019.
  2. I don't want to just put my personal creds in again (see #1). So I can either make a bot just for minibroker, or move two quay which lets you make robot accounts for stuff like this which is much easier to manage. So I'm thinking move to quay.
  3. Travis was bought and gutted, we should move off of travis for our CI as well.

😱

upgrade from 0.3.1 to 1.0.0 RC4 fails (cannot patch "minibroker" with kind ClusterRoleBinding)

My attempted upgrade from 0.3.1. to 1.0.0 RC4 failed with the following error:

Error: UPGRADE FAILED: cannot patch "minibroker" with kind ClusterRoleBinding: ClusterRoleBinding.rbac.authorization.k8s.io "minibroker" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"minibroker-minibroker"}: cannot change roleRef

$ helm version
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T23:30:39Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-17T12:00:00Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Creation of a service fails using cf-service

Issue

When we try to create a service or delete it , that fails and minibroker reports errors

cf create-service postgresql 10-8-0 my-postgresql
cf service my-postgresql
Showing info of service my-postgresql in org redhat.com / space demo as admin...
name:             my-postgresql
service:          postgresql
tags:
plan:             10-8-0
description:      Helm Chart for postgresql
documentation:
dashboard:
service broker:   minibroker
Showing status of last operation from service my-postgresql...
status:    create failed
message:   service instance "05c1d5e1-0907-4766-bcff-0e1c9a057f1d" failed to provision
started:   2020-04-07T16:28:37Z
updated:   2020-04-07T16:28:40Z
There are no bound apps for this service.
Upgrades are not supported by this broker.

OR

cf ds -f my-postgresql

Log of minibroker

[snowdrop@h01-116 temp]$ kc logs -n minibroker minibroker-minibroker-798cd8d755-n8bw6 -c minibroker | grep 05c1d5e1-0907-4766-bcff-0e1c9a057f1d
I0407 16:28:37.730041       1 apisurface.go:89] Received ProvisionRequest for instanceID "05c1d5e1-0907-4766-bcff-0e1c9a057f1d"
I0407 16:28:37.730081       1 broker.go:77] Provisioning 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (postgresql/postgresql-10-8-0) in minibroker
I0407 16:28:37.746937       1 broker.go:92] Successfully initiated provisioning 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (postgresql/postgresql-10-8-0) in minibroker
E0407 16:28:39.951269       1 minibroker.go:335] Failed to provision "05c1d5e1-0907-4766-bcff-0e1c9a057f1d": rpc error: code = Unknown desc = validation failed: unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta2"
I0407 16:28:40.490011       1 apisurface.go:233] Received LastOperationRequest for instanceID "05c1d5e1-0907-4766-bcff-0e1c9a057f1d"
I0407 16:28:40.490046       1 broker.go:120] Getting last operation of 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (<nil>/<nil>)
I0407 16:28:40.492868       1 broker.go:132] Successfully got last operation of 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (<nil>/<nil>): &{State:failed Description:0xc42008e580}
I0407 16:55:09.477239       1 apisurface.go:169] Received DeprovisionRequest for instanceID "05c1d5e1-0907-4766-bcff-0e1c9a057f1d"
I0407 16:55:09.477299       1 broker.go:97] Deprovisioning 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (postgresql/postgresql-10-8-0)
I0407 16:55:09.491970       1 broker.go:114] Successfully initiated deprovisioning 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (postgresql/postgresql-10-8-0)
E0407 16:55:09.493592       1 minibroker.go:600] Failed to deprovision "05c1d5e1-0907-4766-bcff-0e1c9a057f1d": could not delete release : rpc error: code = Unknown desc = no release provided
I0407 16:55:12.711746       1 apisurface.go:233] Received LastOperationRequest for instanceID "05c1d5e1-0907-4766-bcff-0e1c9a057f1d"
I0407 16:55:12.711791       1 broker.go:120] Getting last operation of 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (<nil>/<nil>)
I0407 16:55:12.715522       1 broker.go:132] Successfully got last operation of 05c1d5e1-0907-4766-bcff-0e1c9a057f1d (<nil>/<nil>): &{State:failed Description:0xc42044fb70}

postgres provisioning failing

When attempting to provision a postgres database (plan 11-0-0), the Kubernetes cluster is reporting the following error on container creation.

Error executing 'postInstallation': 2019-04-22 15:39:31.391 UTC [90] FATAL:  data directory "/opt/bitnami/postgresql/data" has wrong ownership
2019-04-22 15:39:31.391 UTC [90] HINT:  The server must be started by the user that owns the data directory.

Allow binding parameters to override credentials

Following up on #99 (comment), it was very hidden that it would be possible to override the credentials while binding. We need a proper mechanism for this and have clear documentation on how it works.

An option would be to allow a key overrides to be passed to the binding request:

{ "overrides": { "mongodbDatabase": "foo" } }

This is useful if somehow the user created extra databases for other apps.

Minibroker relies on the search path for the cluster domain

This behaviour will break when used with the next version of KubeCF with its custom apps-dns. This is because the Garden containers don't set the search path on /etc/resolv.conf when custom nameservers are provided.

What means for Minibroker is that instead of setting the URI in the credentials like mysql.<namespace>.svc, it will need to mysql.<namespace>.svc.<cluster_domain>. The cluster domain is not a constant (even though it's usually set to cluster.local). A way to determine it is by querying the kubernetes.default.svc from the Minibroker container that has the search path set by Kubernetes. E.g.:

awk 'match($0, /search.*\ssvc\.([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}).*$/, cg) { print cg[1] }' /etc/resolv.conf

Since we don't have awk, we can use Go to read /etc/resolv.conf and perform the same regex match.

cf create-service-broker minibroker issue

Hi - this could be a newbie/operator issue running locally, but I am getting an error after running the command "cf create-service-broker minibroker user pass http://minibroker-minibroker.minibroker.svc.cluster.local".

Description: {
"description": "The service broker could not be reached: http://minibroker-minibroker.minibroker.svc.cluster.local/v2/catalog",
"error_code": "CF-ServiceBrokerApiUnreachable",
"code": 10001,
"http": {
"uri": "http://minibroker-minibroker.minibroker.svc.cluster.local/v2/catalog",
"method": "GET"
}
}

repro steps :
minikube start --kubernetes-version=v1.10.0 --bootstrapper=kubeadm

kubectl apply -f https://raw.githubusercontent.com/Azure/helm-charts/master/docs/prerequisities/helm-rbac-config.yaml

helm init --service-account tiller --wait

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install --name catalog --namespace svc-cat svc-cat/catalog --wait

--cf installation
helm repo add minibroker https://minibroker.blob.core.windows.net/charts
helm install --name minibroker --namespace minibroker minibroker/minibroker
--set "deployServiceCatalog=false"
--set "defaultNamespace=minibroker"

helm upgrade --install minibroker
--recreate-pods --force minibroker/minibroker
--set imagePullPolicy="Always",deploymentStrategy="Recreate"

stable/postgresql broken after 2.0.0 chart release

This change: helm/charts@7f1e47c#diff-55277ba53f205867d3498bc5c67e178bL13

...from PR 8004 breaks postgresql in minibroker because postgresPassword is now postgresqlPassword.

The service instance is still created, but when you try to bind it to an application (in CF) you get errors like:

Unexpected Response
Response code: 502
CC code:       0
CC error code: 
Request ID:    e2128dfa-ce26-43f6-6aa5-b3145dcf002a::f43a701a-f8df-4e06-9355-5b000c8df052
Description:   {
  "description": "Service broker error: unable to bind instance 1cdb13b8-2588-4f4d-8352-fe2fdb643e00: postgres-password not found in secret keys",
  "error_code": "CF-ServiceBrokerBadResponse",
  "code": 10001,
  "http": {
    "uri": "http://minibroker-minibroker.minibroker.svc.cluster.local/v2/service_instances/1cdb13b8-2588-4f4d-8352-fe2fdb643e00/service_bindings/4fb42865-7903-4b86-9837-7a8a9ca8036d?accepts_incomplete=true",
    "method": "PUT",
    "status": 500
  }
}

FAILED

Helm chart and include a securityContext that includes runAsUser: 0

The minibroker chart assumes that all PSPs allow you to run as root. Kubernetes will attempt to validate the pod spec against each available PSP in alphabetical order and choose the first PSP that validates the spec.

The pod spec is supposed to list all required privileges in a securityContext. The minibroker doesn't specify that it intends to run as root, so it validates against the the first PSP that validates the spec, but when it tries to run under a more restrictive PSP, it is not allowed to do so.

One way to fix this would be to modify the minibroker chart and include a securityContext that includes runAsUser: 0, so the pod would no longer validate against a PSP that does not allow running as root.

Provisioning mariadb in KubeCF

I have a running KubeCF environment, where iam trying to bring the minibroker

I have followed the following steps on the server.

helm create namespace minibroker
helm install minibroker minibroker/minibroker   --namespace minibroker   --set "deployServiceCatalog=false"   --set "defaultNamespace=minibroker"

From the CF Client Side.
cf create-service-broker minibroker user pass http://minibroker-minibroker.minibroker.svc.cluster.local
cf enable-service-access mariadb
cf create-service mariadb 10-3-21 mariadb-svc3

From the server side again.


opensuse@kubecf-master:~> kubectl get pods -n  minibroker
NAME                                     READY   STATUS    RESTARTS   AGE
minibroker-minibroker-6cb8f6458b-q2gfb   1/1     Running   0          11m

kubectl logs minibroker-minibroker-6cb8f6458b-q2gfb -n  minibroker
I0118 02:34:25.975022       7 klog.go:58] helm client: initializing
I0118 02:34:25.975154       7 klog.go:58] helm client: downloading index file
I0118 02:34:29.192734       7 klog.go:58] helm client: loading repository
I0118 02:34:31.414859       7 klog.go:58] helm client: successfully initialized
I0118 02:34:31.416860       7 main.go:146] starting broker!
I0118 02:34:31.416902       7 server.go:112] Starting server on :8080
I0118 02:35:37.779061       7 minibroker.go:293] minibroker: provisioning intance "ea6415ab-d9af-4cfe-a630-3697dab80306", service "mariadb", namespace "minibroker", params &{map[db:map[name:default user:dbuser] metrics:map[enabled:false] replication:map[enabled:false] resources:map[limits:map[cpu:500m memory:512Mi] requests:map[cpu:200m memory:256Mi]]]}
I0118 02:35:37.842641       7 minibroker.go:378] minibroker: provisioning mariadb/mariadb-10-3-21 using helm chart [email protected]

I waited for some time, and tried multiple times. I dont know where to check the logs. What am i missing ?

Rename import names to new repo

Currently import names are github.com/osbkit/ due to the change to the kubernetes repo we should change this to github.com/kubernetes-sigs/ for all imports and makefiles to match the current repo.

If no objections I can begin the process and submit a PR for this.

Is this project in use by anyone?

At this time, the kubernetes project is considering archiving this project. It may still be forked and maintained externally, however there does not appear to be enough momentum in project to keep it going.

If you are a user of this project, please chime in on this thread.

Extend Bind to access provisioning parameters

Following up on #82 (comment), we need a mechanism that will allow us to discover information that is not present in the secrets produced during provisioning.

The example in the referred link is a good one. If the username is passed during provisioning, it's not known, nor discoverable during binding.

If we change the Bind method to also take the provisioning parameters, we can combine what the defaults are and what the user provided.

ayyyy, 1.x, nice

nice πŸ‘ great stuff. that's all. no issue.

thanks for all the time and energy and advocacy folks put into minibroker, OSBAPI, service bindings, and everything that goes into it. please forgive the issue spam, I'm not sure if there's a slack or anything, i'm kind of being lazy by not looking for it, but--

regardless, just wanted to say thanks πŸ‘

Support installing minibroker in a namespace

Our helm chart assumes installing as a ClusterServiceBroker. I think that will need to be configurable, maybe with a flag like clusterScoped and then also if I install multiple brokers the rbac config shouldn't collide.

Follow up on the context.TODO() items from #72

PR #72 introduced lots of context.TODO(). This was due to the bumping of the k8s libraries.
Minibroker must create proper contexts and pass them around with the requests. It will also enable future timeout implementations and tracing.

Not able to provision a service

Hi there,

After minibroker being deployed, I was trying to create a mariadb service. Two pods were created and pending:

NAME                                                               READY   STATUS    RESTARTS   AGE
mariadb-4144419a028d4d1620c1-master-0   0/1         Pending   0                68m
mariadb-4144419a028d4d1620c1-slave-0      0/1         Pending   0                68m

And the pod description show error:

Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  26s (x46 over 65m)  default-scheduler  0/3 nodes are available: 3 pod has unbound immediate PersistentVolumeClaims.

I check the PV, there was no PV created.

Any idea how to solve this problem?

Thank you!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.