<div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px"><p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><br></p><div></div></div></div></div></div></div></div></div></div></div></div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 2:19 PM Shawn Hurley <<a href="mailto:shurley@redhat.com">shurley@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">I think I would question using an operator to create serviceInstances and serviyBindings. I think doing it this way has one too many abstraction and is not going to play super nice. </div><div dir="auto"><br></div><div dir="auto">Also, I assume the problem is the broker your using requires the secret to do some cleanup and/unbind the user? </div></div></blockquote><div>From what I have been able to investigate this morning, the serviceBindings (which contains a reference to a ServiceInstance) must be first deleted before to delete the ServiceInstance. When we delete the serviceBindings, then all the secret referenced (= having a ownerReference to the serviceBinding) will be then deleted.</div><div>By consequence, I have implemented the same logic within the operator</div><div><br></div><div>if a CRD is deleted, then we delete the serviceBindings linked to the serviceInstance name defined within the CRD and finally the serviceInstance [1]</div><div><br></div><div>[1] <a href="https://goo.gl/WtNJ8v">https://goo.gl/WtNJ8v</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">In this case I would use owner references but I would use a finalized to handle the clean up. This means deleting the binding then the instance then the secret in that order to make sure everything goes well.</div></div></blockquote><div>To be able to use  owner references, then we need a way to define the order, otherwise the resources will not be necessarily deleted according tothis order  : serviceBindings > secrets > serviceInstance but instead in parallel serviceInstance, serviceBindings,... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br></div><div dir="auto">As for force deleting, I don’t think that any code should be doing that automatically. Force delete should be a user action. To do this you delete the finalizer kubernetes-incubator/service-catalog on the service binding and the service instance.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Shawn Hurley </div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 3:23 AM Charles Moulliard <<a href="mailto:cmoullia@redhat.com" target="_blank">cmoullia@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>We have developed a CRD responsible, with the help of an operator, to create k8s resources such as serviceInstance, serviceBinding and secret. When the serviceInstance, serviceBinding are created, we add ownerReferences to allow the CRD to do the garbage collection of such resources.</div><div><br></div><div>Example</div><div><br></div><div><div>oc get serviceinstance/my-postgresql-db -o yaml<br></div><div>apiVersion: <a href="http://servicecatalog.k8s.io/v1beta1" target="_blank">servicecatalog.k8s.io/v1beta1</a></div><div>kind: ServiceInstance</div><div>metadata:</div><div>  creationTimestamp: 2018-10-22T16:23:16Z</div><div>  deletionGracePeriodSeconds: 0</div><div>  deletionTimestamp: 2018-10-23T07:11:42Z</div><div>  finalizers:</div><div>  - kubernetes-incubator/service-catalog</div><div>  generation: 2</div><div>  labels:</div><div>    app: my-spring-boot-service</div><div>    name: my-spring-boot-service</div><div>  name: my-postgresql-db</div><div>  namespace: my-spring-app</div><div>  ownerReferences:</div><div>  - apiVersion: <a href="http://component.k8s.io/v1alpha1" target="_blank">component.k8s.io/v1alpha1</a></div><div>    blockOwnerDeletion: true</div><div>    controller: true</div><div>    kind: Component</div><div>    name: my-spring-boot-service</div><div>    uid: c7aee0ee-d616-11e8-9b27-08002710b4d8</div><div>...</div><div><br></div></div><div>Unfortunately, when we delete the CRD, the secret is deleted but not the ServiceInstance & serviceBinding which are marked for deletion</div><div><br></div><div>The status mentions such info for the serviceInstance</div><div><br></div><div><div>  - lastTransitionTime: 2018-10-23T07:00:04Z</div><div>    message: All associated ServiceBindings must be removed before this ServiceInstance</div><div>      can be deleted</div><div>    reason: DeprovisionBlockedByExistingCredentials</div><div>    status: "False"</div><div>    type: Ready</div></div><div><br></div><div>and for the serviceBinding</div><div><br></div><div>  Warning  UnbindCallFailed  3m (x63 over 18m)  service-catalog-controller-manager  Error unbinding from ServiceInstance "my-spring-app/my-postgresql-db" of ClusterServiceClass (K8S: "1dda1477cace09730bd8ed7a6505607e" ExternalName: "dh-postgresql-apb") at ClusterServiceBroker "openshift-automation-service-broker": Status: 403; ErrorMessage: <nil>; Description: User does not have sufficient permissions; ResponseError: <nil><br></div><div><br></div><div>okd version used : 3.11</div><div><br></div><div>Question :</div><div>- Can we use "ownerReferences" to delete from a CRD the service's k8s resources ?</div><div>- What is the alternative if we can use "ownerReferences" ?</div><div>- How can we force to delete such k8s resources ?</div><div><br></div><div>Regards</div><div><br></div><div>Charles<br></div><div><div><div dir="ltr" class="gmail-m_-3038367151585068768m_37685467008620782gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px"><div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Ansible-service-broker mailing list<br>
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank">Ansible-service-broker@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/ansible-service-broker</a><br>
</blockquote></div></div>
</blockquote></div></div></div>