Re: [GitHub] mdeuser commented on issue #3804: Error in installing route management actions under Ubuntu

[Carlos Santana]

You can use curl get http on /namespaces if you get a list of namespaces 
([“whisk.system”]) then controller can access DB and is ready accept package 
and actions create/put 

- Carlos Santana
@csantanapr

> On Jul 3, 2018, at 6:07 PM, GitBox  wrote:
> 
> mdeuser commented on issue #3804: Error in installing route management 
> actions under Ubuntu
> URL: 
> https://github.com/apache/incubator-openwhisk/issues/3804#issuecomment-402306107
> 
> 
>   i agree that a different solution is preferred.  is there a more 
> deterministic way for the controller to indicate it's ready to accept 
> requests? moving the .yml around only varies the timing window without 
> guaranteeing the routemgmt package will be installed.  it might be that other 
> packages in postdeploy may experience the same issue.
> 
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> With regards,
> Apache Git Services

Re: [VOTE] Release Apache OpenWhisk 0.9.0-incubating rc2: main OpenWhisk module

[Rodric Rabbah]

This was removed:

> On Jul 3, 2018, at 2:55 PM, Vincent S Hou  wrote:
> 
> 
> The MD5 checksum for each artifact can be found via:
> https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz.md5
>  
> 

[VOTE] Release Apache OpenWhisk 0.9.0-incubating rc2: main OpenWhisk module

[Vincent S Hou]

Hi everyone,

This is to call for a vote for the release of Apache OpenWhisk 0.9.0-incubating 
rc2: main OpenWhisk module.

We have resolved all the issues regarding the dependency's license, gradle 
wrapper, some documentation issues, etc, based on we discussed during last 
voting mail thread for rc1.

This release comprises of source code distribution only. There is one module 
within this release. The artifact was built from the following Git commit ID:
* openwhisk: b1476b9, add until for all ansible retries (#3806)

The source code artifacts can be found at:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz

The MD5 checksum for each artifact can be found via:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz.md5

The SHA-512 checksum for each artifact can be found via:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz.sha512

The signature of this artifact can be found via:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/openwhisk-0.9.0-incubating-sources.tar.gz.asc

KEYS file is available here:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS

The documentation can be found via:
https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.9.0-incubating-rc2/doc/INSTALL.md

Please vote on releasing this package as Apache OpenWhisk 0.9.0-incubating rc2.

The vote will be open for at least 72 hours.
[ ] +1 Release as Apache OpenWhisk 0.9.0-incubating
[ ] +0 no opinion
[ ] -1 Do not release and the reason

Checklist for reference:
[ ] Download links are valid.
[ ] Checksums and PGP signatures are valid.
[ ] Source code artifacts have correct names matching the current release.
[ ] LICENSE and NOTICE files are correct for each OpenWhisk repo.
[ ] All files have license headers if necessary.
[ ] No compiled archives bundled in source archive.

Thank you very much.

Best wishes.
Vincent Hou (侯胜博)

Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud

Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States

Re: Proposing Ballerina Runtime for OpenWhisk

[Rodric Rabbah]

Thank you Malith for introducing Ballerina to OpenWhisk.

We have received in the past contributions to add PHP (thanks @akrabat
), Go
 (thanks
@sciabarracom ) Ruby (#3725
 thanks @remore
) so far but have not documented the steps
required to add a new runtime so that it is available to the OpenWhisk
deployment. I've taken this opportunity to create a first draft after
working through to reduce the touch-points needed to integrate the runtime
with OpenWhisk in recent weeks.

Comments  are appreciated and welcome particularly from those who have
contributed runtimes in the past.
https://github.com/rabbah/openwhisk/blob/2672826f1b8e75549c3f15b3fa35b673ee23becd/docs/actions-new.md

I think there are some more things we can do to reduce the steps needed as
noted in the markdown. I'd like to make sure I covered the big steps first.

-r

On Tue, Jul 3, 2018 at 6:14 AM, Malith Munasinghe 
wrote:

> *Hi All, I have initiated this thread to introduce Ballerina [1] Language
> Runtime for OpenWhisk. Ballerina is a simple programming language whose
> syntax and platform address the hard problems of integration. Ballerina is
> a general purpose, concurrent, transactional, statically and strongly typed
> programming language with both textual and graphical syntaxes. Its
> specialization is integration - it brings fundamental concepts, ideas and
> tools of distributed system integration into the language and offers a type
> safe, concurrent environment to implement such applications. These include
> distributed transactions, reliable messaging, stream processing, workflows
> and container management platforms.The implementation of the OpenWhisk
> language runtime for Ballerina (0.975.0) can be found in repository [2] and
> relevant docker image can be found in [3]. I would like to donate this to
> Apache Incubator OpenWhisk project as a new Runtime. Please share your
> thoughts on necessary actions to be taken to contribute this code to
> OpenWhisk project. [1] https://ballerina.io/  [2]
> https://github.com/mpmunasinghe/openwhisk-runtime-ballerina
>  [3]
> https://hub.docker.com/r/mpmunasinghe/balaction/
> *
>
> --
>
> *With regards,*
> *Malith Munasinghe*
>
> *@mpmunasinghe*
>

Re: No test code in the release? (was: [DISCUSS] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module)

[Vincent S Hou]

Hi Bertrand,

The reason we do not ship the tests in the artifact for this release is that 
there are test files with unidentified licenses, which may bring risks in when 
we distribute them.

After we resolve the license issues, we will package them in the source code 
artifact.

 
Best wishes.
Vincent Hou (侯胜博)

Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud

Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States

-Bertrand Delacretaz  wrote: -
To: dev@openwhisk.apache.org
From: Bertrand Delacretaz 
Date: 07/03/2018 04:33AM
Subject: No test code in the release? (was: [DISCUSS] Release Apache OpenWhisk 
0.9.0-incubating: main OpenWhisk module)

Hi,

On Mon, Jul 2, 2018 at 10:52 PM Vincent S Hou  wrote:
> ...I have proposed a PR fixing all the issues raised in this mail thread: 
> https://github.com/apache/incubator-openwhisk-release/pull/218 ...

I noticed the "Since this release does not ship the code of test
cases.." comment there.

What's the plan for these test cases, are they part of a separate module?

If yes, I think future releases of these modules should be synced, so
that people know which set of tests to use against a version of the
core release.

This is not an urgent problem, I'm just trying to understand the idea.

-Bertrand

Connection reuse in the Invoker (HttpUtils)

[Markus Thoemmes]

Hi OpenWhiskers,

I (and potentially Tyson in 
https://github.com/apache/incubator-openwhisk/issues/3151) found a pretty nasty 
bug which is very spurious, but hear me out:

Today, we employ a connection pool when talking to our user-containers. The 
assumption is that connections are reused between requests, a performance 
improvement. If a container is not used for some time (aka pause-grace) we 
pause it, effectively freezing the container. The container (and its socket) 
will not answer to any requests coming from the outside for the time of being 
paused.

When that container is to be used again, we resume it and then try to reuse one 
of the connections I talked about earlier. These connections can go stale 
though. The server might close them before further notice and my expectation 
is, that pausing/resuming adds another layer of uncertainty on the state of the 
connection. The PoolingConnectionManager does staleness checks after a 
connection has been idle for 2 seconds. This staleness checking involves 
writing into the socket and observing what happens. Per documentation 
(https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/RequestConfig.html),
 it's an expensive procedure that can take up to 30ms, which in my opinion, 
completely negates the performance optimization it's geared towards. After all, 
we might not be reusing many connection anyway, if they go stale pretty quick 
due to pause/resume.

Furthermore, there is this problem (per: 
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html):

> HttpClient tries to mitigate the problem by testing whether the connection is 
> 'stale', that is no longer valid because it was closed on the server side, 
> prior to using the connection for executing an HTTP request. The stale 
> connection check is not 100% reliable. The only feasible solution that does 
> not 
> involve a one thread per socket model for idle connections is a dedicated 
> monitor thread used to evict connections that are considered expired due to a 
> long period of inactivity. The monitor thread can periodically call 
> ClientConnectionManager#closeExpiredConnections() method to close all expired 
> connections 
> and evict closed connections from the pool. It can also optionally call 
> ClientConnectionManager#closeIdleConnections() method to close all 
> connections that 
> have been idle over a given period of time.

I think in our case this is a bit overengineered and propose the following:

We throw away all connections in the pool upon pausing the container. A 
connection will be reestablished after resuming it. This will reuse connections 
under bursts (in the pause-grace) but should safely recreate connections when 
pausing/unpausing. As I said above, this might be pretty close the behavior 
we're having anyway, but makes it less prone to timing errors and much more 
explicit.

This might well explain the strange issues we had when we first used akka-http 
in our invoker -> user-container communication. @Tyson this would then have an 
impact on the work you're doing.

Let me know what you think,
-m

Proposing Ballerina Runtime for OpenWhisk

[Malith Munasinghe]

*Hi All, I have initiated this thread to introduce Ballerina [1] Language
Runtime for OpenWhisk. Ballerina is a simple programming language whose
syntax and platform address the hard problems of integration. Ballerina is
a general purpose, concurrent, transactional, statically and strongly typed
programming language with both textual and graphical syntaxes. Its
specialization is integration - it brings fundamental concepts, ideas and
tools of distributed system integration into the language and offers a type
safe, concurrent environment to implement such applications. These include
distributed transactions, reliable messaging, stream processing, workflows
and container management platforms.The implementation of the OpenWhisk
language runtime for Ballerina (0.975.0) can be found in repository [2] and
relevant docker image can be found in [3]. I would like to donate this to
Apache Incubator OpenWhisk project as a new Runtime. Please share your
thoughts on necessary actions to be taken to contribute this code to
OpenWhisk project. [1] https://ballerina.io/  [2]
https://github.com/mpmunasinghe/openwhisk-runtime-ballerina
 [3]
https://hub.docker.com/r/mpmunasinghe/balaction/
*

-- 

*With regards,*
*Malith Munasinghe*

*@mpmunasinghe*

Re: Recover image pulls by trying to run the container anyways.

[Rodric Rabbah]

+1 to make the change - as noted this is for the better in terms of running 
docker actions in prod. 

-r

> On Jul 3, 2018, at 3:07 AM, Markus Thoemmes  
> wrote:
> 
> Hi,
> 
> Thanks for the clarification Rodric, wasn't aware of that. I think it still 
> holds though that "latest" should mean "always pull and inform me if you 
> failed" vs. other tags meaning "it's okay to swallow an occasional pull issue 
> if that means my app runs just fine".
> 
> For future work, we could add the ability to pass digest information along 
> with the image, which'd enable us to locally verify the image vs. having to 
> do a network roundtrip.
> 
> Any concerns on the behavioral change initially proposed in the meantime? 
> Should we hold back on the merge or can we go ahead?
> 
> Cheers,
> -m
> 

No test code in the release? (was: [DISCUSS] Release Apache OpenWhisk 0.9.0-incubating: main OpenWhisk module)

[Bertrand Delacretaz]

Hi,

On Mon, Jul 2, 2018 at 10:52 PM Vincent S Hou  wrote:
> ...I have proposed a PR fixing all the issues raised in this mail thread: 
> https://github.com/apache/incubator-openwhisk-release/pull/218 ...

I noticed the "Since this release does not ship the code of test
cases.." comment there.

What's the plan for these test cases, are they part of a separate module?

If yes, I think future releases of these modules should be synced, so
that people know which set of tests to use against a version of the
core release.

This is not an urgent problem, I'm just trying to understand the idea.

-Bertrand

Re: Recover image pulls by trying to run the container anyways.

[Markus Thoemmes]

Hi,

Thanks for the clarification Rodric, wasn't aware of that. I think it still 
holds though that "latest" should mean "always pull and inform me if you 
failed" vs. other tags meaning "it's okay to swallow an occasional pull issue 
if that means my app runs just fine".

For future work, we could add the ability to pass digest information along with 
the image, which'd enable us to locally verify the image vs. having to do a 
network roundtrip.

Any concerns on the behavioral change initially proposed in the meantime? 
Should we hold back on the merge or can we go ahead?

Cheers,
-m