ibm/cloud-operators

Provision and bind IBM Cloud services to your Kubernetes cluster in a Kubernetes-native way

cloud-operators's Issues

uninstall script did not remove ibmcloud-operator-manager-role

ibmcloud-operator-manager-role does not have labels and was not removed by running uninstall-operator.sh.

Document behavior of `self-healing` annotation

There is a closed issue (#11) that added an annotation to control the self-healing behavior and there is at least one example that includes the self-healing annotation.

However, there is no documentation anywhere else as to what exactly this is doing and how to apply it. I believe this annotation will address an issue on my project but I'm hesitant to use it without getting a better understanding of how it works.

Missing stable releases

Hi, is that possible to create any release tag to publish the stable version instead of always installing with the latest master.zip?

Long provision times for Binding should not Fail (expect Pending)

Example: postgresql

DB2 sample needs to be updated, plan & service name have changed

Document that binding secret keys will replace spaces with underscores

Question: The secret in the binding, can it be revoked or rotated?

The usage docs describe:

A Binding generates a secret with the same name as the binding resource and contains service credentials that can be consumed by your application.

Is there anyway to revoke or rotate the secret?

Thinking of use cases where the secret has been compromised or if it needs to be rotated periodically due to some biz security policy.

If there is a better place to ask such questions please let me know.

Thank You

Make fields of binding spec immutable

Mitigate the denial of service from Bluemix

Deletion fails for cloudant, if service is manually deleted first on bluemix

{"level":"info","ts":1583890921.6279922,"logger":"service","msg":"Error deleting resource","my-cloudant":"Request failed with status code: 400, ServerErrorResponse: {"message":"Instance is pending reclamation. Please restore the instance and retry.","status_code":400,"transaction_id":"bss-47d37a02da442b8d"}\n"}

Console UI fails to load for example `mystreams` service

I followed the instructions to create a service and binding for Streams (e.g., mystreams service instance). The service and binding are created. When I click on the mystreams service from the OCP cluster console I get an empty page which you cannot go back.

Looking in the web browser console I see the following error.

`WebSocket connection to 'wss://console.dan-rhos10-f0a5715bb2873122b708ede2bf765701-0001.us-east.containers.appdomain.cloud/api/kubernetes/apis/ibmcloud.ibm.com/v1alpha1/namespaces/default/services?watch=true&fieldSelector=metadata.name%3Dmystreams&x-csrf-token=XXXXXXXXXXXX' failed: WebSocket is closed before the connection is established.
o.destroy @ index.tsx:52'

Deletion of Service/Binding CRD instances failed to delete service instance

Context:

I was testing an example application example that uses an instance of the Watson Language Translator from the IBM cloud. I was using an IKS 1.14.x cluster with cloudoperators/ibmcloud-operator:0.1.0 installed.

At the start of a sequence of operations, I had no instances of binding or service CRDs in the cluster and no instances of the Watson Language Translator in my cloud account.

At the end of a sequence of operations, I had no instances of binding or service CRDs in the cluster, BUT there was still an instance of the Watson Language Translator in my cloud account (still there 24 hours later). Based on the name of the instance, it was the one created by the ibmcloud operator and not deleted when the CRDs were deleted.

Attached is the relevant section of logs from the operator.

log.txt

Generate an Activity Tracker event for service creation

When using the IBM Cloud operator, any service creation results in a service creation event is logged into Activity Tracker. Currently, because of the way IBM Cloud operator works, the initiator will be corresponding to the API key/service id used by AT instead of the actual user who initiate the service creation. The request here is to add a feature to Cloud operator to create an additional service creation event that shows the actual user who created the service.

It might be possible to some how create a service with the user's name, then we don't need another AT event.

Please contact me if you have any questions.

Make default namespace configurable

operator should look for seed-secret in current namespace, and if not present, in the namespace specified in seed-defaults, using a naming convention (one seed-secret per namespace)

Fix Travis build (TAG now required in env)

install-operator.sh is failed due to I don't know how to create secret

$ curl -sL https://raw.githubusercontent.com/IBM/cloud-operators/master/hack/install-operator.sh | bash

• Downloading install yaml...
  error: error validating "STDIN": error validating data: [unknown object type "nil" in Secret.data.api-key, unknown object type "nil" in Secret.data.region]; if you choose to ignore these errors, turn validation off with --validate=false

.travis.yml: The 'sudo' tag is now deprecated in Travis CI

Travis are now recommending removing the sudo tag.

"If you currently specify sudo: false in your .travis.yml, we recommend removing that configuration"

Bug for service provisioning with multiple bindings

I provision a cloudant service with multiple bindings according to the following yaml file:

apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Service
metadata:
  name: my-cloudant
spec:
  plan: standard 
  serviceClass: cloudantnosqldb
---
apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Binding
metadata:
  name: my-binding-cloudant-1
spec:
  serviceName: my-cloudant
---
apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Binding
metadata:
  name: my-binding-cloudant-2
spec:
  serviceName: my-cloudant

However, I can see there are two service instances in IBM Cloud Portal resource list, one has two bindings, another one has none, showing as below:

Deletion of Binding corresponding to a Failed service fails

account information checks from config-operator.sh

Sometimes when using the IBM Cloud CLI, the region is not being set resulting in IC_REGION being empty. This results in rather obscure errors during secret creation like:

error: error validating “STDIN”: error validating data: unknown object type “nil” in Secret.data.region; if you choose to ignore these errors, turn validation off with --validate=false

It would be helpful to do a quick validation of the IC... fields in this script and putting up an error message to help users spot and fix the CLI session configuration issue.

secretName in Binding spec was not used for secret name

Tried the binding operator with the following yaml. It appears that the operator did not name the secret with secretName as specified in yaml. The secret was named binding-messagehub instead of laura-messagehub-secret.

apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Binding
metadata:
  name: binding-messagehub
spec:
  serviceName: mymessagehub
  secretName: laura-messagehub-secret

Can not provision IBM service with a service id

I used a IBM cloud service id(Administrator role)'s apikey to provision a service by using cloud-operator the latest release, the error threw:
Request failed with status code: 400, BXNIM0106E: Validation of property 'response_type' with value '[uaa, cloud_iam]' failed. Valid values: 'cloud_iam, delegated_refresh_token'

I have verified that with the service id's api key, I can successfully provision service by using ibmcloud cli.
So does cloud-operator support service id?

Put seed-default /seed-secrets into an `admin-only` accessible workspace

Per @paolo, Another one is to create secrets in an admin-only accessible workspace, with some naming convention, such as ico-secret- and have the operator look up there as well to get the API key. This way we can keep a even better separation and use kube best practices for management of secrets.

Let us use this issue to track this feature development.

Make parameters for Service updatable

Resources with Alias plan should consider external name

Document usage of `secretName` in Binding

We should document the usage of secretName in Binding.

Add parameters to Binding and Service

Add IBM Cloud Tag to managed resources

[Question] Where does the olm was published

I found that we have a folder for olm https://github.com/IBM/cloud-operators/tree/master/olm , the question is for on-line install, where I can get those olm files? From operatorhub or some other places?

Problem when creating a service that can only have one instance

Some services such as DB2 can only have one instance created for the free plan.
So if there is already such a service instantiated, and another one is created with this operator then that fails.

However, if the existing service is deleted then the operator should recover and create a new instance (since the reason for failure no longer exists). This does not happen and we are left with an ill-formed object that has no Status.State.

Bindging did not detect credential removal on remote service

When a credential (originally created by Binding operator) is deleted manually on IBM cloud console, Binding operator did not detect the missing credential and the old secret remained unchanged.

Cannot create a binding to existing Cloudant service

I'm trying to apply this yaml:

apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Binding
metadata:
    name: cloudant
spec:
    plan: Alias
    serviceName: cloudant
    serviceClass: cloudantnosqldb

After applying and waiting 3-4mn I see:

Status:
  Message:  Processing Resource
  State:    Pending

It'd be nice if the status section reports what's wrong with either spec or my configuration.

The status of a service that takes a long time to provision is not updated appropriately

Improve Documentation

Document the following:

• When a binding is deleted the associated secret is deleted as well. One way to refresh credentials is to delete a binding and recreate
• Document the meaning of all optional parameters of Service and Binding
• Elaborate on how to obtain service and plan names
• Explain global region in the context for some services
• Explain why some services display an inactive or failed status until they become online (that we simply channel the status coming from Bluemix)
• Add section on Credential aliases
• Add section on immutability of some fields in Service spec

Rename seed-default and seed-secrets

Per discussion in #91, I created a new issue to bring this up

===================

@pdettor I just curious, are the names seed-secret and seed-defaults configurable? If we put them into the end-user's namespace where the service/bind resource being created, I would like to use a more explicitly name , i.e. secret-ibm-cloud-operator and config-ibm-cloud-operator to avoid the deletion by end-user.

Answered by @vazirim
@cdlliuy Sure, we can rename.

===================

Make self-healing controllable via annotation

Currently self-healing is enabled by default. Since that might not be always desirable, especially for stateful services, we should control self-healing with an annotation such as:

annotations:
    ibmcloud.ibm.com/self-healing: enabled

Label not present or any other value than enabled should disable the self-healing feature.

seed-secret-tokens is recreated every 30 seconds

2019/09/04 11:10:30 Registering Components.
{"level":"info","ts":1567595430.383996,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"binding-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1567595430.384281,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"binding-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1567595430.384528,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"service-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1567595430.3847806,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"token-controller","source":"kind source: /, Kind="}
2019/09/04 11:10:30 Starting the Cmd.
{"level":"info","ts":1567595430.4853036,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"token-controller"}
{"level":"info","ts":1567595430.4853926,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"binding-controller"}
{"level":"info","ts":1567595430.485429,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"service-controller"}
{"level":"info","ts":1567595430.585615,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"token-controller","worker count":1}
{"level":"info","ts":1567595430.5858042,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"service-controller","worker count":30}
{"level":"info","ts":1567595430.5857067,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"binding-controller","worker count":33}
{"level":"info","ts":1567595430.5860016,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595430.5862157,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595431.5611506,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595431.6002471,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595460.457385,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595460.457479,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595461.023003,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595461.1133666,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595490.4581864,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595490.4582605,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595490.6674898,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595490.7247064,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595520.459059,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595520.4591346,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595520.7943714,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595520.8722453,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595550.459095,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595550.459168,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595550.6792963,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595550.7460973,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595580.4596167,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595580.4597182,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595581.3568347,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595581.4320064,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595610.4605396,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595610.4606142,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595610.647946,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595610.7103074,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595640.4604962,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595640.4605722,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595641.455251,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595641.5189216,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595670.4615536,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595670.4616308,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595670.781947,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595670.8239803,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595700.4620593,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595700.46217,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595701.2653816,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595701.4408503,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595730.4625704,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595730.4626958,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595731.3687491,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595731.6761453,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595760.4628518,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595760.4629266,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595762.2687404,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595762.9215274,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595790.4639907,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595790.4640663,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595790.766511,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595790.893934,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595820.4639208,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595820.464038,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595821.0999365,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595821.1949873,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595850.4647455,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595850.464858,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595851.0882504,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595851.1474195,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595880.4655426,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595880.4656255,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595881.6596067,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595881.7811937,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595910.4656918,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595910.4657555,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595910.7067425,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595910.7580051,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595940.466467,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595940.4665887,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595941.3466737,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595941.4124768,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567595970.46677,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567595970.4668615,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567595970.9634576,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567595971.0092242,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567596000.467724,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567596000.4677951,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567596000.628489,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567596000.7129726,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567596030.4676917,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567596030.4677715,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567596030.6161482,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567596030.6956184,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}
{"level":"info","ts":1567596031.6005745,"logger":"iam-token","msg":"reconciling IBM cloud IAM tokens","secretRef":"seed-secret"}
{"level":"info","ts":1567596031.6007035,"logger":"iam-token","msg":"authenticating..."}
{"level":"info","ts":1567596032.3850238,"logger":"iam-token","msg":"creating tokens secret","name":"seed-secret-tokens"}
{"level":"info","ts":1567596032.4597018,"logger":"iam-token","msg":"secret created","name":"seed-secret-tokens"}

Support existing services

Re-introduce the ability to reference and bind existing services via usage of the Alias plan.

FEATURE: Leverage IAM identity of kubernetes user when applicable (IKS and Red Hat OpenShift on IBM Cloud)

When using IKS or Red Hat OpenShift on IBM Cloud users are authenticating with openshift/kubernetes with an IBM Cloud IAM identity. Any thoughts on if it would be possible to use this identity for authentication with IBM Cloud when trying to manage the services?

It may be a pipedream, but I do think it's worth investigation to see if there could be a method for leveraging this identity.

Example COS service with binding not working

https://github.com/IBM/cloud-operators/blob/master/config/samples/cos.yaml

Message: Failed: No deployment found for service plan lite at location us-south. Valid location(s) are: ["global"].

Object description:

Name:         b2c-auth-dev-cos-dal-01-test
Namespace:    tpol
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"ibmcloud.ibm.com/v1alpha1","kind":"Service","metadata":{"annotations":{},"name":"b2c-auth-dev-cos-dal-01-test","namespace":...
API Version:  ibmcloud.ibm.com/v1alpha1
Kind:         Service
Metadata:
  Creation Timestamp:  2019-09-04T12:02:39Z
  Generation:          1
  Resource Version:    16278396
  Self Link:           /apis/ibmcloud.ibm.com/v1alpha1/namespaces/tpol/services/b2c-auth-dev-cos-dal-01-test
  UID:                 e4a0f379-cf0b-11e9-a426-e27ade6abd72
Spec:
  Plan:           lite
  Service Class:  cloud-object-storage
Status:
  Context:
    Org:
    Region:
    Resourcegroup:
    Resourcelocation:
    Space:
  Message:             Failed: No deployment found for service plan lite at location us-south. Valid location(s) are: ["global"].
Use service instance example if the service is a Cloud Foundry service
  Plan:                lite
  Service Class:       cloud-object-storage
  Service Class Type:
  State:               Failed
Events:                <none>

Deleting a service that has just been deleted manually from Console fails

{"level":"info","ts":1572487334.5800693,"logger":"service","msg":"Error deleting resource","mytranslator":"Request failed with status code: 400, ServerErrorResponse: {"message":"Instance is already in pending_reclamation state.","status_code":400}\n"}

The controller doesn't recover from this

Adopt the descriptors from the service binding specification

Once we have RC1 of the service binding specification and SBO supports it, all that IBM Cloud's operator would have to do to be considered compliant with the spec is update its x-descriptor to also use the spec's annotation (which should be very similar), and another simple update to claim that it is bindable.

Requires service.ibmcloud instances to be created in the default namespace

It's not finding the secret in the default namespace.

olm $ oc describe service.ibmcloud
Name:         mypersonality
Namespace:    ibmcloud
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"ibmcloud.ibm.com/v1alpha1","kind":"Service","metadata":{"annotations":{},"name":"mypersonality","namespace":"ibmcloud"},"spec":{"plan":"...
API Version:  ibmcloud.ibm.com/v1alpha1
Kind:         Service
Metadata:
  Creation Timestamp:  2019-07-10T19:29:16Z
  Generation:          1
  Resource Version:    16373
  Self Link:           /apis/ibmcloud.ibm.com/v1alpha1/namespaces/ibmcloud/services/mypersonality
  UID:                 017c240f-a349-11e9-8052-229d59c3b269
Spec:
  Plan:           lite
  Service Class:  personality-insights
Status:
  Context:
    Org:
    Region:
    Resourcegroup:
    Resourcelocation:
    Space:
  Message:             Secret "seed-secret" not found
  Plan:                lite
  Service Class:       personality-insights
  Service Class Type:
  State:               Failed
Events:                <none>

Cloudant with Alias plan: existence checks sometimes fails, gets recreated

The controller should not recreate an Alias service.
Recreating an existing Cloudant service seems to crash it and causes its deletion.

bindings fail for sysdig

apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Service
metadata:
    name: sysdiglite
spec:
    plan: lite
    serviceClass: sysdig-monitor
---
apiVersion: ibmcloud.ibm.com/v1alpha1
kind: Binding
metadata:
    name: binding-sysdiglite
spec:
    serviceName: sysdiglite

The result is that the service.ibmcloud is just fine, but i get the following for the binding.ibmcloud

Name:         binding-sysdiglite
Namespace:    default
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"ibmcloud.ibm.com/v1alpha1","kind":"Binding","metadata":{"annotations":{},"name":"binding-sysdiglite","namespace":"default"},"spec":{"ser...
API Version:  ibmcloud.ibm.com/v1alpha1
Kind:         Binding
Metadata:
  Creation Timestamp:  2019-07-11T15:08:01Z
  Finalizers:
    binding.ibmcloud.ibm.com
  Generation:  1
  Owner References:
    API Version:           ibmcloud.ibm.com/v1alpha1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Service
    Name:                  sysdiglite
    UID:                   acea4390-a3ed-11e9-a260-7a9326862861
  Resource Version:        6010884
  Self Link:               /apis/ibmcloud.ibm.com/v1alpha1/namespaces/default/bindings/binding-sysdiglite
  UID:                     acf32645-a3ed-11e9-a260-7a9326862861
Spec:
  Service Name:  sysdiglite
Status:
  Instance Id:      crn:v1:bluemix:public:sysdig-monitor:us-south:a/33c5711b8afbf7fd809a4529de613a08:0d1d43af-29e8-4098-a7ad-f1252f5ca684::
  Key Instance Id:  crn:v1:bluemix:public:sysdig-monitor:us-south:a/33c5711b8afbf7fd809a4529de613a08:0d1d43af-29e8-4098-a7ad-f1252f5ca684:resource-key:0e21964e-e3d2-4c63-82f4-c4ccdd42af04
  Message:          Secret "binding-sysdiglite" is invalid: [data[Sysdig Access Key]: Invalid value: "Sysdig Access Key": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[Sysdig Collector Endpoint]: Invalid value: "Sysdig Collector Endpoint": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[Sysdig Customer Id]: Invalid value: "Sysdig Customer Id": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[Sysdig Endpoint]: Invalid value: "Sysdig Endpoint": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
  State:            Failed
Events:             <none>

Use UBI image as the base image?

Is that possible to publish ibm-cloud-operator with http://registry.access.redhat.com/ubi8-minimal image?

Request to create `release` tag and upload deployment yaml file as releases assets

The current installation approach in https://github.com/IBM/cloud-operators/blob/master/hack/install-operator.sh#L37 is not friendly enough to end-user.

Suggest to create releases for this version, and attach the yaml files as releases assets, so that we can use https://github.com/IBM/cloud-operators/releases/download/.....yaml to do the installation.

Also, suggest to create an overall yaml file for deployment as well .

Immutability check in service controller failing

Create a translator
Change serviceClass to messagehub
Result is 3 services (2 messagehubs and 1 translator)

Operator creates an excessive number of policy entries

Each time a binding CR is created, it creates a corresponding credential in the service even if a credential of the same name already exists on that service.

Each credential, in turn, creates an access policy against the account.

An account has a hard limit of 600 policies that can be created. In several accounts, using the IBM Cloud operator on a medium scale deployment has resulted in policy limit to be hit.

This may be compounded by some other issue in the Operator where the credentials are not cleaned up properly when the service is destroyed and/or the Operator creating orphaned policies when it removes/re-creates the binding.

Add docs for service context info