<div dir="ltr">Hi John<div><br><div class="gmail_extra"><div class="gmail_quote"><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">Please let us know if you are still seeing 404's with apb development.</div></blockquote><div><br></div><div>to tell the truth I am very surprised here. It seems that with the change from Jason apb is now constantly going to /openshift-automation-service-broker/v2/catalog instead of /ansible-service-broker/v2/catalog. This is good for the latest development branch, but is a non-go for those working with older releases. This change broke apb cli for me for opensfhit 3.9. The ease to get this change merged waves in me suspicion, that apb/asb project is not mature enough to be used productively. There is no stability, and instead  things are being constantly changed.</div><div><br></div><div>First there were nulecule/atomicapp. They was abandoned without a note in the project (now it is mentioned in the repo, but this was not the case even recently). Later APB appeared. First with "k8s_v1_persistent_volume_claim"-like direct modules, which are is still adverted in all docs and `apb init`. With Ansible-2.5 there is a shift to `openshift_raw`, `k8s_raw` (it is visible only in example apbs, and not mentioned in the docs). Now there is a switch to `k8s` for ansible-2.6 and `xxx_raw` modules are being not only deprecated, but removed from ansible (ok, renamed not to be used, but still). And again there is no documentation in the APB/ASB with respect to that. With nearly quarterly releases of Ansible, do I need to rewrite my app in sync with the things you guys "trying"? To tell the truth it feels like being not even a beta, but alpha tester. However RedHat announces and recommends using it since I guess 3.6 (during local Openshift meetups)</div><div><br></div><div>Then we come to the issue with apb development setup. I do not want to say it so, but I can't find any other words: there is no development setup. minishift is not actively supported by apb/asb team, since each time I mention minishift in IRC I get immediately an answer, that you are not using it. On the other hand I have not found a way to try at least soon to be released openshift 3.10 there. Trivial APBs are of course working with 3.9. Problem is that with 3.9 in minishift I am not able to proceed with async binding (which I need mainly because of binding parameters).</div><div>catasb project is instead by default giving you latest development version of components, which brings following issues with it:</div><div>- I am not able to reliably setup workspace due to not yet clarified issues. On a completely fresh system it starts and works, but from the second time `oc cluster up` step of the local/linux/run_setup_local.sh fails (whether I do not specify tags at all, or specify 3.10 - just return code 1, the cluster is being started, but not usable due to aborted install; <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">plain `oc cluster up` still works</span>). Even removing /var/lib/origin, /tmp/origin*, ~/-kube, /var/lib/docker does not help. If I set it to use 3.9 images it is starting correctly, but the you have the same "async binding" issues, as with minishift</div><div>- Setting myself using "official" release (3.9 as of now) does not seem to bring me lot of use, since I doubt you would backport fixes for found problems (at least those mentioned in the original mail) back to 3.9. What about 3.10? With a 3.10 release soon I doubt this also. In addition I need to enable "not supported" features in the config. This might be still ok for early POC, but not for real solution. </div><div>- with previously mentioned issue with change in apb cli I can't use it now with older (3.9, compared to devel) releases.</div><div>- I would have tried getting catasb to install me 3.10, but how do I do this? How do I figure out, which tag of the asb will be part of 3.10? (<a href="https://hub.docker.com/r/ansibleplaybookbundle/origin-ansible-service-broker/tags/">https://hub.docker.com/r/ansibleplaybookbundle/origin-ansible-service-broker/tags/</a>)</div><div>- catasb is goold in general, but it assumes being active developer of ASB team. Relying only to README you are doomed.</div><div><br></div><div>I truly prefer ASB to Helm, but as I mentioned: is it mature enough to invest time? I love RedHat products, I do myself have a red RedHat hat :-), but I am always warned, since products at RedHat are being born and die very frequently (surely normal dev process, but I can't invest corporate resources into something that may die or change direction in 6 month).</div><div><br></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 dir="ltr"><div></div><div>As to the async bind issues you noted:</div><div> - needing to use asb_encode_binding even if no data needs to be passed back</div><div>    Sounds like a bug, we can address if you would open an issue.</div></div></blockquote><div><br></div><div>sure, will open one. But I would first need to clarify whether this is valid in 3.9 only or also in devel </div><div><br></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 dir="ltr"><div> - issue with complex content in asb_encode_binding</div><div>    This may be more challenging to address, if you'd open an issue with an example we can investigate.<br><div><div><br></div></div></div></div></blockquote><div><br></div><div>sure, will open one. Need a reliable apb dev workspace, which is a problem as I mentioned</div><div><br></div><div><br></div><div>With the best regards,</div><div>Artem</div></div></div></div></div>