<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think this is will simplify life as we make breaking changes. <div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 1, 2018, at 12:52 PM, David Zager <<a href="mailto:dzager@redhat.com" class="">dzager@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Greetings,<div class=""><br class=""></div><div class="">This email is meant to get feedback on a fix to an issue was raised against the broker project regarding the <a href="https://github.com/openshift/ansible-service-broker/issues/912" class="">run_latest_build.sh version check</a>. The issue, as Jesus had predicted <a href="https://github.com/openshift/ansible-service-broker/pull/891#discussion_r182487585" class="">two weeks ago</a>, is that our version check is not very strong. While we could correct the version check to properly handle semantic versioning, I believe we should take this as an opportunity to bring the run_latest_build script and run_latest_k8s_build script into one.</div><div class=""><br class=""></div><div class="">You may ask "What would this look like?". Only the run_latest_build.sh would be left standing and it would:</div><div class=""><ol class=""><li class="">Expect a cluster (Kubernetes|OpenShift) to already exist with service-catalog installed</li><li class="">Create the broker namespace</li><li class="">Create a service account for the <a href="https://github.com/automationbroker/automation-broker-apb" class="">automation-broker-apb</a></li><li class="">Create a automation-broker-apb clusterrolebinding "cluster-admin" tied to the automation-broker-apb service account</li><li class="">Run the automation-broker-apb as a pod</li><li class="">Delete the automation-broker-apb pod</li><li class="">Delete the automation-broker-apb service account</li><li class="">Delete the automation-broker-apb clusterrolebinding</li></ol><div class="">Since the automation-broker-apb will detect the cluster type and do the right thing (always, no bugs here). We can simply launch the pod and watch.</div></div></div></div></blockquote><div>We already noticed that this can handle the issues that we have been having w/ the deployment template in catasb. Catasb uses master template but master tracks the canary image. If we also move catasb to using the APB then we can handle that situation with logic.</div><div>You can see an example of this with the latest CRD changes that Zager helped me with. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Removing the cluster startup from run_latest_build.sh was brought up during the ansible-service-broker IRC meeting which would make it virtually equivalent to the run_latest_k8s_build.sh. Having a single run_latest_build script is one step in a long process of simplifying our onboarding process with the benefit of reducing ways broker installs could fail.</div></div></div></div></blockquote><div>+1</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Your feedback is appreciated.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Zager</div></div>
_______________________________________________<br class="">Ansible-service-broker mailing list<br class=""><a href="mailto:Ansible-service-broker@redhat.com" class="">Ansible-service-broker@redhat.com</a><br class="">https://www.redhat.com/mailman/listinfo/ansible-service-broker<br class=""></div></blockquote></div><br class=""></div></div></body></html>