<div dir="ltr">I agree with having bind/unbind playbooks that are called on those actions. However, in this case at least, a bind playbook didn't place the secret in the deployment config, the Openshift ?Console? did. This sounds like a bug against origin. If there is a process for adding the secret to the deployment then there should be a process that removes it.</div><span>
</span><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 4, 2018, 11:59 AM Dylan Murray <<a href="mailto:dymurray@redhat.com" target="_blank">dymurray@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like it. Makes sense and fits the inital approach we wanted to take. It would also be useful for Amazon APBs to remove credentials from RDS for example.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 11:07 AM, Ryan Hallisey <span dir="ltr"><<a href="mailto:rhallise@redhat.com" target="_blank">rhallise@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael,<br>
<br>
I agree there is a gap here.  In the past with pod presets, the<br>
catalog managed the relationship<br>
between the app and the bind.  Until the catalog has another solution,<br>
maybe we can deal with<br>
this with an unbind apb playbook. The playbook will get called from<br>
the broker unbind action,<br>
an apb will run for each app in the bind, and the reference to the<br>
secret will be removed by the<br>
playbook.<br>
<br>
What are folks thoughts on that?<br>
<br>
Thanks,<br>
- Ryan<br>
<div><div class="m_-2463993673162599319m_-5981628092474769611h5"><br>
<br>
On Wed, Jan 3, 2018 at 5:10 PM, Michael Hrivnak <<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>> wrote:<br>
> Looking at this BZ, and continuing a discussion from IRC:<br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1511760" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1511760</a><br>
><br>
> It seems there is a gap in the lifecycle of the secret that gets created by<br>
> a binding. When the ServiceBinding gets deleted (such as via the binding's<br>
> "Delete" link in the UI), its secret gets deleted too. But if that secret<br>
> had been added to a DeploymentConfig, that DC retains a reference to the<br>
> secret. Any re-deployment will fail.<br>
><br>
> What is the missing step? Something should presumably clean up any<br>
> references to the secret, which in this case would mean updating the<br>
> DeploymentConfig. What should implement that business logic?<br>
><br>
> --<br>
><br>
> Michael Hrivnak<br>
><br>
> Principal Software Engineer, RHCE<br>
><br>
> Red Hat<br>
><br>
><br>
</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>
><br>
<br>
_______________________________________________<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><br></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>