For me, what Chetan suggested makes sense and sounds very attractive. We are observing a lot of questions and novices suffering from setting up OpenWhisk.
The standalone jar would be a great alternative for the quick start if they have no preference for fundamental tech(compose, k8s, etc). Best regards Dominic 2019년 7월 19일 (금) 오후 2:53, Chetan Mehrotra <chetan.mehro...@gmail.com>님이 작성: > For switching to standalone jar we would first need to publish it > (#4525). Once we make it available for download somewhere we can then > guide users to download it from there > > > I also like the standalone JAR. Should we consider adding to that the API > Management features made available through OW GW, or for that we should > keep the docker-compose route > > If we would like to simplify the Api GW usage specially with > standalone case then we can possibly try adding some support for it > within standalone flow itself > > 1. Package the route management action zips in jar > 2. Upon startup (say with -g flag) it would install the routes > 3. It would then also spin up required containers like api gw, redis, > minio? > > So end user may just need to run with `-g` flag to get the gateway > functionality working. > > Chetan Mehrotra > > On Sat, Jul 13, 2019 at 12:40 AM Rodric Rabbah <rod...@gmail.com> wrote: > > > > > I also like the standalone JAR. Should we consider adding to that the > API > > Management features made available through OW GW, or for that we should > > keep the docker-compose route ? > > > > I did get the API gateway to run (in the container) with standalone > > openwhisk. I ran the ansible playbook (wskdev apigw) to get it up and > > going. It doesn't work with sls (serverless framework because of the DNS > > resolution issue I've posted about in the past) but will work with wsk. > > > > -r >
