<div dir="ltr">Ravi,<div><br></div><div>I know that some of the example APBs and apb init, have separate roles for provision and deprovision that make provision/deprovision cumbersome. We have been toying with a single role approach in the form of an example (<a href="https://github.com/ansibleplaybookbundle/hello-world-apb/pull/3/files">https://github.com/ansibleplaybookbundle/hello-world-apb/pull/3/files</a>). My understanding is that this would simplify the development of an APB with the introduction of the <a href="https://github.com/djzager/Hello-World-APB/blob/e96daf23ccb06a999a7755c2da4253a8031d2b86/roles/hello-world-apb/defaults/main.yml#L7-L10">'state_map'</a> and having the objects we want either <a href="https://github.com/djzager/Hello-World-APB/blob/e96daf23ccb06a999a7755c2da4253a8031d2b86/roles/hello-world-apb/tasks/main.yml#L18-L21">'present' or 'absent' based on the 'state'</a>. Would love your feedback (and anyone who wants to chime in) on that reference example. This is still being actively discussed, but I do believe that a single role approach simplifies the provision/deprovision scenarios of an APB.</div><div><br></div><div>Regards,</div><div>David</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 14, 2018 at 1:23 PM Ravi Jonnadula <<a href="mailto:ravijo@gmail.com">ravijo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div dir="auto">One suggestion I would like to make is to let APB automatically build deprovision-playbook based on the provision-playbook, instead of letting it to the user to define. That IMO will minimize the possibility of deprovision failure  as long as provision succeeds.</div></div></div><div dir="auto"><br></div><div dir="auto">Of course, this deprovision-playbook need to be maintained by APB internally corresponding to each provisioned module and maintain association between them.</div></div><div dir="auto"><br></div><div dir="auto">Ravi</div><div><div><div><br><div class="gmail_quote"><div>On Wed, Feb 14, 2018 at 9:16 AM Philip Gough <<a href="mailto:pgough@redhat.com" target="_blank">pgough@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>Sure, I'll get something going asap.</div><div><div><br></div><div>Philip</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 5:09 PM, Ryan Hallisey <span><<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"><div><div>> So while sure adding this flag seems to fix one aspect of it, albeit a<br>
> key aspect, it would be better to see a proposal on dev experience from<br>
> a developer perspective. And try to address the issues outlined and<br>
> discussed. That discussion might lead to this exact patch, but it will<br>> be seen in the broader picture of how to fix the dev experience.<br>><br>Sounds good, let's go with a broader dev proposal.  Philip, is that something you would be wiling to start? Here's a link to the template <a href="https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/proposal-template.md" target="_blank">https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/proposal-template.md</a><br><br></div>-Ryan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 11:49 AM, jesus m. rodriguez <span><<a href="mailto:jesusr@redhat.com" target="_blank">jesusr@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>On Wed, 2018-02-14 at 11:29 -0500, Ryan Hallisey wrote:<br>
> > > I don’t know if I feel comfortable with adding this logic to the<br>
> > > primary<br>
> > > code path for deprovision. This is mostly me being conservative<br>
> > > with<br>
><br>
> adding<br>
> > > configuration values that can allow things to get deleted from<br>
> > > our<br>
><br>
> storage.<br>
> > ><br>
> ><br>
> > The developer experience is not acceptable right now, but I have to<br>
> > agree with Shawn.<br>
> ><br>
><br>
</span></span><span><span>> Agreed, the dev experience is really rough with deprovision. For<br>
> instance,<br>
> if you are testing your provision playbook with the broker and your<br>
> deprovision playbook fails, then you can't test provision again<br>
> without<br>
> some manually steps.  But, I think Phillip's patch is a good way to<br>
> provide<br>
> significant improvement to the dev experience with minimal code<br>
> changes.<br>
> The meat of his code is 4 lines:<br>
><br>
> ```go<br>
> if a.brokerConfig.ForceDelete {<br>
>   log.Infof("Deprovision failed. Attempting to clean up related<br>
> resources.<br>
> User should ensure clean up is successful")<br>
>   cleanupDeprovision(&instance, a.dao) // Return a 200 to the<br>
> service-catlog<br>
> }<br>
> ```<br>
<br>
</span></span>I think the problem is not necessarily that it is a seemingly small<br>
patch. But that there is an overall bigger issue that the dev<br>
experience isn't completely thought out yet.<br>
<br>
So while sure adding this flag seems to fix one aspect of it, albeit a<br>
key aspect, it would be better to see a proposal on dev experience from<br>
a developer perspective. And try to address the issues outlined and<br>
discussed. That discussion might lead to this exact patch, but it will<br>
be seen in the broader picture of how to fix the dev experience.<br>
<br>
My hesitation with applying this right now is I'd rather see what the<br>
broader list of dev experience problems are. How we can address them?<br>
Do we have a single flag that enables a bunch of things? Do we have a<br>
set of dev flags that can be flipped for individual things? Etc.<br>
<br>
We already have a dev_broker flag. Now this patch is adding a<br>
force_delete flag. While it is to fix a dev experience problem, how do<br>
I know that flag is just for dev? What are the implications of enabling<br>
said flag in a production environment? It's the list of subtleties that<br>
I'd like to at least see or anticipate before addressing just one<br>
aspect of a problem.<span><br>
<span><br>
><br>
> > Unless I missed it, let's backup and describe the high-level<br>
> > problem<br>
> > in a proposal and<br>
> > submit solutions there. That's been our approach thus far and I<br>
> > think<br>
> > it applies here well.<br>
><br>
> To make this the default behaviour, I agree needs a proposal.<br>
<br>
</span></span>I would rather have a proposal to discuss the dev experience and needs.<br>
Then have a series of PRs to address the needs that come from that<br>
proposal. Again this patch fixes only one aspect of the dev experience.<br>
<span class="m_6032424932685050657m_-5861644269047274235m_2869219916535075062m_-9196040076028167619m_-5875523734182106090HOEnZb"><font color="#888888"><br>
jesus<br>
</font></span><span><div class="m_6032424932685050657m_-5861644269047274235m_2869219916535075062m_-9196040076028167619m_-5875523734182106090HOEnZb"><div class="m_6032424932685050657m_-5861644269047274235m_2869219916535075062m_-9196040076028167619m_-5875523734182106090h5"><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>
</div></div></span></blockquote></div><br></div>
</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></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>