Re: Try out the api gateway support in standalone server (#4571)
This all works perfectly for me (including the APIGW!). Super
impressed as always.
The only thing remaining I'd like to see is the option to additionally
add the event sources (couchdb, alarm, kafka, etc). If this is
available, I would start using it in different CI/CD pipelines for
testing.
Would definitely +1 on getting this "officially" released. It is such
a great option for users playing around locally. We all see so many
user issues with people struggling to get the platform working with
other deployment types in Slack etc.
On Tue, 30 Jul 2019 at 09:53, Chetan Mehrotra wrote:
>
> Thanks Dominic for testing it out!
>
> > the system came up cleanly, and as relayed on Slack, I think it would be
> > useful to hoist the messages that gw is ready up to where the system checks
> > are first printed so they aren't lost in all the output that follows which
> > for the most part, users should be able to ignore.
>
> @Rodric Rabbah Thats done now. On startup first dependent services are
> started like Redis and ApiGw and a summary report is logged detailing
> what all services are running and at what port
>
>
> Launched service details
>
> [ 6379 ] Redis (whisk-redis)
> [ 9000 ] Api Gateway - Api Service (whisk-apigw)
> [ 3234 ] Api Gateway - Management Service (whisk-apigw)
>
> Local working directory - /Users/chetanm/.openwhisk/standalone/server-3233
>
>
> Would connect on chat to see why the issue is coming for you.
>
> Chetan Mehrotra
>
> On Tue, Jul 30, 2019 at 11:48 AM Dominic Kim wrote:
> >
> > For me, it works as expected.
> > I followed the steps in Ubuntu16.04 with Docker-18.06.3.
> >
> >
> > style95@style95-ubuntu:~/tmp$ wsk list -i
> > Entities in namespace: default
> > packages
> > actions
> > triggers
> > rules
> > style95@style95-ubuntu:~/tmp$ wsk api list -i
> > ok: APIs
> > ActionVerb API Name URL
> > style95@style95-ubuntu:~/tmp$ wsk action create hello hello.js --web true -i
> > ok: created action hello
> > style95@style95-ubuntu:~/tmp$ wsk api create /hello /world get hello
> > --response-type json -i
> > ok: created API /hello/world GET for action /_/hello
> > http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
> > style95@style95-ubuntu:~/tmp$ curl
> > http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
> > {
> > "payload": "Hello world Serverless API"
> > }
> >
> > I tried it again on MacOS wtih Docker 18.06.1-ce, and it also works as
> > expected.
> >
> > Thank you for the great work Chetan :+1:
> >
> > Dear Rabbah
> > Regarding the issue, if you need any further information from my side
> > please let me know.
> >
> >
> > Best regards
> > Dominic
> >
> >
> > 2019년 7월 29일 (월) 오후 11:52, Rodric Rabbah 님이 작성:
> >
> > > Hi Chetan,
> > >
> > > this is fantastic... I followed your instructions here as is even though I
> > > noticed the gw PR was merged already and in theory I should be able to
> > > drop
> > > the image override.
> > >
> > > the system came up cleanly, and as relayed on Slack, I think it would be
> > > useful to hoist the messages that gw is ready up to where the system
> > > checks
> > > are first printed so they aren't lost in all the output that follows which
> > > for the most part, users should be able to ignore.
> > >
> > > i tried creating an API as documented in [2] but hit a snag. The
> > > controller
> > > received this request from the gateway:
> > >
> > > [#tid_bEVIJzQ...] GET //localhost:3233/api/v1/web/guest/default/hello.json
> > >
> > > but this doesn't match any routes in the controller and the API returns
> > > with a 404. The prefix "//localhost:3233/" needs to be omitted, I'm not
> > > yet
> > > sure where it's coming from. I suspect you'll know right away.
> > >
> > > These are the logs from the gw for the failed request:
> > >
> > > ==> /var/log/api-gateway/access.log <==
> > > 172.17.0.1 - remote_user="-" [29/Jul/2019:14:50:45 +]
> > > request_method="GET"
> > > request_uri="/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world"
> > > request_protocol="HTTP/1.1" status=404 bbs=96 rl=130 rt=0.008 hr="-"
> > > ua="curl/7.54.0" xfwdf="-" upadd="192.168.65.2:3233" upstat=404 uprt=0.007
> > > tenantId="23bc46b1-71f6-4ed5-8c54-816aa4f8c502"
> > > tenantNamespace="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantInstance=""
> > > requestHeaders="" requestBody="" responseHeaders="" responseBody=""
> > > apiId="8a68d0a9-a024-4411-9233-7ba1d9099b1a" apiKey="-"
> > > analyticsUri="/hello/world" reqid="zvL6RbV0qtiZ0BakfDGudINV8Gzv1Ocl"
> > >
> > > ==> /var/log/api-gateway/gateway_error.log <==
> > > 2019/07/29 14:50:45 [info] 35#0: *21 client 172.17.0.1 closed keepalive
> > > connection
> > > 2019/07/29 14:50:48 Executing sync cmd: echo ''
> > > sync stdout | ''
> > > 2019/07/29 14:50:48 done
> > >
> > >
>
Re: Try out the api gateway support in standalone server (#4571)
Thanks Dominic for testing it out!
> the system came up cleanly, and as relayed on Slack, I think it would be
> useful to hoist the messages that gw is ready up to where the system checks
> are first printed so they aren't lost in all the output that follows which
> for the most part, users should be able to ignore.
@Rodric Rabbah Thats done now. On startup first dependent services are
started like Redis and ApiGw and a summary report is logged detailing
what all services are running and at what port
Launched service details
[ 6379 ] Redis (whisk-redis)
[ 9000 ] Api Gateway - Api Service (whisk-apigw)
[ 3234 ] Api Gateway - Management Service (whisk-apigw)
Local working directory - /Users/chetanm/.openwhisk/standalone/server-3233
Would connect on chat to see why the issue is coming for you.
Chetan Mehrotra
On Tue, Jul 30, 2019 at 11:48 AM Dominic Kim wrote:
>
> For me, it works as expected.
> I followed the steps in Ubuntu16.04 with Docker-18.06.3.
>
>
> style95@style95-ubuntu:~/tmp$ wsk list -i
> Entities in namespace: default
> packages
> actions
> triggers
> rules
> style95@style95-ubuntu:~/tmp$ wsk api list -i
> ok: APIs
> ActionVerb API Name URL
> style95@style95-ubuntu:~/tmp$ wsk action create hello hello.js --web true -i
> ok: created action hello
> style95@style95-ubuntu:~/tmp$ wsk api create /hello /world get hello
> --response-type json -i
> ok: created API /hello/world GET for action /_/hello
> http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
> style95@style95-ubuntu:~/tmp$ curl
> http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
> {
> "payload": "Hello world Serverless API"
> }
>
> I tried it again on MacOS wtih Docker 18.06.1-ce, and it also works as
> expected.
>
> Thank you for the great work Chetan :+1:
>
> Dear Rabbah
> Regarding the issue, if you need any further information from my side
> please let me know.
>
>
> Best regards
> Dominic
>
>
> 2019년 7월 29일 (월) 오후 11:52, Rodric Rabbah 님이 작성:
>
> > Hi Chetan,
> >
> > this is fantastic... I followed your instructions here as is even though I
> > noticed the gw PR was merged already and in theory I should be able to drop
> > the image override.
> >
> > the system came up cleanly, and as relayed on Slack, I think it would be
> > useful to hoist the messages that gw is ready up to where the system checks
> > are first printed so they aren't lost in all the output that follows which
> > for the most part, users should be able to ignore.
> >
> > i tried creating an API as documented in [2] but hit a snag. The controller
> > received this request from the gateway:
> >
> > [#tid_bEVIJzQ...] GET //localhost:3233/api/v1/web/guest/default/hello.json
> >
> > but this doesn't match any routes in the controller and the API returns
> > with a 404. The prefix "//localhost:3233/" needs to be omitted, I'm not yet
> > sure where it's coming from. I suspect you'll know right away.
> >
> > These are the logs from the gw for the failed request:
> >
> > ==> /var/log/api-gateway/access.log <==
> > 172.17.0.1 - remote_user="-" [29/Jul/2019:14:50:45 +]
> > request_method="GET"
> > request_uri="/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world"
> > request_protocol="HTTP/1.1" status=404 bbs=96 rl=130 rt=0.008 hr="-"
> > ua="curl/7.54.0" xfwdf="-" upadd="192.168.65.2:3233" upstat=404 uprt=0.007
> > tenantId="23bc46b1-71f6-4ed5-8c54-816aa4f8c502"
> > tenantNamespace="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantInstance=""
> > requestHeaders="" requestBody="" responseHeaders="" responseBody=""
> > apiId="8a68d0a9-a024-4411-9233-7ba1d9099b1a" apiKey="-"
> > analyticsUri="/hello/world" reqid="zvL6RbV0qtiZ0BakfDGudINV8Gzv1Ocl"
> >
> > ==> /var/log/api-gateway/gateway_error.log <==
> > 2019/07/29 14:50:45 [info] 35#0: *21 client 172.17.0.1 closed keepalive
> > connection
> > 2019/07/29 14:50:48 Executing sync cmd: echo ''
> > sync stdout | ''
> > 2019/07/29 14:50:48 done
> >
> >
> > -r
> >
> >
> >
> > On Mon, Jul 29, 2019 at 7:53 AM Chetan Mehrotra > >
> > wrote:
> >
> > > Hi Team,
> > >
> > > As discussed in last Tech Interchange call support is now being added
> > > to launch the Api Gateway with Standalone Server [1]. With this it
> > > should be possible to direct new OpenWhisk users to use the Standalone
> > > server to try out various features provided by OpenWhisk
> > >
> > > So far tests look fine and would now like to seek some feedback from
> > > community on this feature. For this it would be helpful if you can try
> > > out a beta build and see if it works as expected
> > >
> > > # Fetch custom docker build of apigateway which has
> > > apache/incubator-openwhisk-apigateway#347 fixed
> > > $ docker pull chetanmeh/apigateway
> > >
> > > # Download the openwhisk-standalone jar
> > > $ wget
Re: Try out the api gateway support in standalone server (#4571)
For me, it works as expected.
I followed the steps in Ubuntu16.04 with Docker-18.06.3.
style95@style95-ubuntu:~/tmp$ wsk list -i
Entities in namespace: default
packages
actions
triggers
rules
style95@style95-ubuntu:~/tmp$ wsk api list -i
ok: APIs
ActionVerb API Name URL
style95@style95-ubuntu:~/tmp$ wsk action create hello hello.js --web true -i
ok: created action hello
style95@style95-ubuntu:~/tmp$ wsk api create /hello /world get hello
--response-type json -i
ok: created API /hello/world GET for action /_/hello
http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
style95@style95-ubuntu:~/tmp$ curl
http://172.17.0.1:3234/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world
{
"payload": "Hello world Serverless API"
}
I tried it again on MacOS wtih Docker 18.06.1-ce, and it also works as
expected.
Thank you for the great work Chetan :+1:
Dear Rabbah
Regarding the issue, if you need any further information from my side
please let me know.
Best regards
Dominic
2019년 7월 29일 (월) 오후 11:52, Rodric Rabbah 님이 작성:
> Hi Chetan,
>
> this is fantastic... I followed your instructions here as is even though I
> noticed the gw PR was merged already and in theory I should be able to drop
> the image override.
>
> the system came up cleanly, and as relayed on Slack, I think it would be
> useful to hoist the messages that gw is ready up to where the system checks
> are first printed so they aren't lost in all the output that follows which
> for the most part, users should be able to ignore.
>
> i tried creating an API as documented in [2] but hit a snag. The controller
> received this request from the gateway:
>
> [#tid_bEVIJzQ...] GET //localhost:3233/api/v1/web/guest/default/hello.json
>
> but this doesn't match any routes in the controller and the API returns
> with a 404. The prefix "//localhost:3233/" needs to be omitted, I'm not yet
> sure where it's coming from. I suspect you'll know right away.
>
> These are the logs from the gw for the failed request:
>
> ==> /var/log/api-gateway/access.log <==
> 172.17.0.1 - remote_user="-" [29/Jul/2019:14:50:45 +]
> request_method="GET"
> request_uri="/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world"
> request_protocol="HTTP/1.1" status=404 bbs=96 rl=130 rt=0.008 hr="-"
> ua="curl/7.54.0" xfwdf="-" upadd="192.168.65.2:3233" upstat=404 uprt=0.007
> tenantId="23bc46b1-71f6-4ed5-8c54-816aa4f8c502"
> tenantNamespace="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantInstance=""
> requestHeaders="" requestBody="" responseHeaders="" responseBody=""
> apiId="8a68d0a9-a024-4411-9233-7ba1d9099b1a" apiKey="-"
> analyticsUri="/hello/world" reqid="zvL6RbV0qtiZ0BakfDGudINV8Gzv1Ocl"
>
> ==> /var/log/api-gateway/gateway_error.log <==
> 2019/07/29 14:50:45 [info] 35#0: *21 client 172.17.0.1 closed keepalive
> connection
> 2019/07/29 14:50:48 Executing sync cmd: echo ''
> sync stdout | ''
> 2019/07/29 14:50:48 done
>
>
> -r
>
>
>
> On Mon, Jul 29, 2019 at 7:53 AM Chetan Mehrotra >
> wrote:
>
> > Hi Team,
> >
> > As discussed in last Tech Interchange call support is now being added
> > to launch the Api Gateway with Standalone Server [1]. With this it
> > should be possible to direct new OpenWhisk users to use the Standalone
> > server to try out various features provided by OpenWhisk
> >
> > So far tests look fine and would now like to seek some feedback from
> > community on this feature. For this it would be helpful if you can try
> > out a beta build and see if it works as expected
> >
> > # Fetch custom docker build of apigateway which has
> > apache/incubator-openwhisk-apigateway#347 fixed
> > $ docker pull chetanmeh/apigateway
> >
> > # Download the openwhisk-standalone jar
> > $ wget
> >
> https://github.com/chetanmeh/incubator-openwhisk/releases/download/0.11/openwhisk-standalone.jar
> > $ java -Dwhisk.standalone.api-gateway.image=chetanmeh/apigateway -jar
> > openwhisk-standalone.jar --api-gw
> >
> > Post this you can use the steps as mentioned in [2] to check out the
> > gateway support.
> >
> > Please share any feedback on #4571 or this mail thread
> >
> > Chetan Mehrotra
> > [1] https://github.com/apache/incubator-openwhisk/pull/4571
> > [2]
> >
> https://github.com/apache/incubator-openwhisk/blob/master/docs/apigateway.md
> >
>
Re: Try out the api gateway support in standalone server (#4571)
Hi Chetan, this is fantastic... I followed your instructions here as is even though I noticed the gw PR was merged already and in theory I should be able to drop the image override. the system came up cleanly, and as relayed on Slack, I think it would be useful to hoist the messages that gw is ready up to where the system checks are first printed so they aren't lost in all the output that follows which for the most part, users should be able to ignore. i tried creating an API as documented in [2] but hit a snag. The controller received this request from the gateway: [#tid_bEVIJzQ...] GET //localhost:3233/api/v1/web/guest/default/hello.json but this doesn't match any routes in the controller and the API returns with a 404. The prefix "//localhost:3233/" needs to be omitted, I'm not yet sure where it's coming from. I suspect you'll know right away. These are the logs from the gw for the failed request: ==> /var/log/api-gateway/access.log <== 172.17.0.1 - remote_user="-" [29/Jul/2019:14:50:45 +] request_method="GET" request_uri="/api/23bc46b1-71f6-4ed5-8c54-816aa4f8c502/hello/world" request_protocol="HTTP/1.1" status=404 bbs=96 rl=130 rt=0.008 hr="-" ua="curl/7.54.0" xfwdf="-" upadd="192.168.65.2:3233" upstat=404 uprt=0.007 tenantId="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantNamespace="23bc46b1-71f6-4ed5-8c54-816aa4f8c502" tenantInstance="" requestHeaders="" requestBody="" responseHeaders="" responseBody="" apiId="8a68d0a9-a024-4411-9233-7ba1d9099b1a" apiKey="-" analyticsUri="/hello/world" reqid="zvL6RbV0qtiZ0BakfDGudINV8Gzv1Ocl" ==> /var/log/api-gateway/gateway_error.log <== 2019/07/29 14:50:45 [info] 35#0: *21 client 172.17.0.1 closed keepalive connection 2019/07/29 14:50:48 Executing sync cmd: echo '' sync stdout | '' 2019/07/29 14:50:48 done -r On Mon, Jul 29, 2019 at 7:53 AM Chetan Mehrotra wrote: > Hi Team, > > As discussed in last Tech Interchange call support is now being added > to launch the Api Gateway with Standalone Server [1]. With this it > should be possible to direct new OpenWhisk users to use the Standalone > server to try out various features provided by OpenWhisk > > So far tests look fine and would now like to seek some feedback from > community on this feature. For this it would be helpful if you can try > out a beta build and see if it works as expected > > # Fetch custom docker build of apigateway which has > apache/incubator-openwhisk-apigateway#347 fixed > $ docker pull chetanmeh/apigateway > > # Download the openwhisk-standalone jar > $ wget > https://github.com/chetanmeh/incubator-openwhisk/releases/download/0.11/openwhisk-standalone.jar > $ java -Dwhisk.standalone.api-gateway.image=chetanmeh/apigateway -jar > openwhisk-standalone.jar --api-gw > > Post this you can use the steps as mentioned in [2] to check out the > gateway support. > > Please share any feedback on #4571 or this mail thread > > Chetan Mehrotra > [1] https://github.com/apache/incubator-openwhisk/pull/4571 > [2] > https://github.com/apache/incubator-openwhisk/blob/master/docs/apigateway.md >
Try out the api gateway support in standalone server (#4571)
Hi Team, As discussed in last Tech Interchange call support is now being added to launch the Api Gateway with Standalone Server [1]. With this it should be possible to direct new OpenWhisk users to use the Standalone server to try out various features provided by OpenWhisk So far tests look fine and would now like to seek some feedback from community on this feature. For this it would be helpful if you can try out a beta build and see if it works as expected # Fetch custom docker build of apigateway which has apache/incubator-openwhisk-apigateway#347 fixed $ docker pull chetanmeh/apigateway # Download the openwhisk-standalone jar $ wget https://github.com/chetanmeh/incubator-openwhisk/releases/download/0.11/openwhisk-standalone.jar $ java -Dwhisk.standalone.api-gateway.image=chetanmeh/apigateway -jar openwhisk-standalone.jar --api-gw Post this you can use the steps as mentioned in [2] to check out the gateway support. Please share any feedback on #4571 or this mail thread Chetan Mehrotra [1] https://github.com/apache/incubator-openwhisk/pull/4571 [2] https://github.com/apache/incubator-openwhisk/blob/master/docs/apigateway.md
