[Ansible-service-broker] Help needed in a dev setup

[Artem Goncharov]

Hi John

Please let us know if you are still seeing 404's with apb development.
>

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.

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)

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).
catasb project is instead by default giving you latest development version
of components, which brings following issues with it:
- 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; plain `oc cluster up` still works). 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
- 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.
- with previously mentioned issue with change in apb cli I can't use it now
with older (3.9, compared to devel) releases.
- 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? (
https://hub.docker.com/r/ansibleplaybookbundle/origin-ansible-service-broker/tags/
)
- catasb is goold in general, but it assumes being active developer of ASB
team. Relying only to README you are doomed.

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).



> As to the async bind issues you noted:
>  - needing to use asb_encode_binding even if no data needs to be passed
> back
>     Sounds like a bug, we can address if you would open an issue.
>

sure, will open one. But I would first need to clarify whether this is
valid in 3.9 only or also in devel



>  - issue with complex content in asb_encode_binding
>     This may be more challenging to address, if you'd open an issue with
> an example we can investigate.
>
>
sure, will open one. Need a reliable apb dev workspace, which is a problem
as I mentioned


With the best regards,
Artem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ansible-service-broker/attachments/20180711/f6e2118a/attachment.htm>