2019-03-12 00:49:07 UTC - Bruce Adams: Sorry to go silent for for a few days. I find myself wondering how we expect Rust developers to use the Rust runtime. I think of usual OpenWhisk language support as having two and sometimes three modes of use. 1) send in a single source file as the action 2) send in an assembled program, allowing for multiple module source code and user bundled dependencies 3) (optionally) make it easy for developers to produce a Docker image directly runnable as an OpenWhisk action. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552351747221900?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 00:49:57 UTC - Bruce Adams: My concern with the current code <https://github.com/apache/incubator-openwhisk-runtime-rust/blob/master/rust1.32/src/action_loop/src/main.rs> is: How does someone pull that into their build (for mode number 2 in my list above)? https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552351797222100?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 00:52:08 UTC - Bruce Adams: I’d much prefer to have all of the code in `main` in there be in a library, published on <https://crates.io/>, that a developer can pull into their build. They would call that library to start the action loop, passing in a reference to their action function. The developer then needs to provide the Rust main program, but that is trivially short. The upside is they get to use conventional Rust build tools (and IDEs, etc). https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552351928222300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 00:54:01 UTC - Roberto Diaz: For number 2) what's the difference respect the current generic native actions? https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352041222600?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 00:58:06 UTC - Roberto Diaz: At the begining talking with @Michele Sciabarra the idea was provide the following options: 1) Uploads a single source file (in case you don't need any additional crate dependency) 2) Upload your code in a zip including at least your `cargo.toml` and your `src/lib.rs` with your function https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352286222800?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 00:59:58 UTC - Roberto Diaz: Using the actionloop the user do not need to worry about the `<http://main.rs|main.rs>` that file is for actionloop internal use https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352398223000?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:01:44 UTC - Bruce Adams: Ah. OK. So, _always_ compiling as part of initialization and allowing for pulling in dependencies. That covers a lot of use cases. (Is that plan written down somewhere?) I guess the scary part with this is that Rust compiles can take a long time. Allowing for built binaries could make for a better init-time story. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352504223200?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:02:45 UTC - Carlos Santana: For prod apps should be same as go and swift upload a zip with the binary/exec already compiled. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352565224100?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:03:04 UTC - Carlos Santana: Minimum init time. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352584224600?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:03:50 UTC - Bruce Adams: That’s what I was thinking. The current Rust setup makes that cumbersome, I think. (I don’t see a clean way to do a local build with the current setup.) https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352630224800?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:05:05 UTC - Roberto Diaz: right now you have to crosscompile your rust code into the generic container arch, zip the binary and create the native action https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352705225000?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:05:38 UTC - Bruce Adams: That doesn’t sound like a `cargo build --release`… https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352738225300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:06:34 UTC - Carlos Santana: Hmm in go and swift we made it dead simple with a Makefile to reuse the docker runtime to compile and create the zip. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352794226400?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:07:43 UTC - Carlos Santana: <https://github.com/apache/incubator-openwhisk-runtime-go/blob/master/examples/golang-main-vendor/Makefile#L23> https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352863226700?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:08:57 UTC - Carlos Santana: <https://github.com/apache/incubator-openwhisk-runtime-swift/blob/master/examples/swift-main-zip/Makefile#L19> https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552352937227000?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:10:49 UTC - Bruce Adams: I don’t know swift. Go I know well enough. That Makefile looks like it carries along a ton of OpenWhisk stuff. I expect a much skinnier interface. If the services I support at work don’t fall apart like they did last week, I’ll sketch out what I’m thinking. It there a place to have design and goal conversations? (Is Slack good enough?) https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353049227200?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:11:26 UTC - Carlos Santana: Sure. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353086227500?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:11:55 UTC - Carlos Santana: I’m familiar with what your describing is literally the AWS Rust Lambda runtime. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353115228400?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:12:22 UTC - Carlos Santana: A function that runs a lib from Lambda that takes the function handler as a parameter https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353142229300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:12:59 UTC - Carlos Santana: <https://github.com/awslabs/aws-lambda-rust-runtime#example-function> https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353179229600?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:13:02 UTC - Bruce Adams: I thought maybe I’d seen something like that for Lambda. I’ve barely touched Lambda. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353182229900?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:13:38 UTC - Bruce Adams: Yup. That’s the kind of thing I was thinking of. Thanks! https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353218230600?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:14:42 UTC - Carlos Santana: I use VSCode with Go and Xcode for Swift no problem developing and using a Local IDE including brakepoints https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353282232100?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:15:09 UTC - Carlos Santana: Makefile is just something that the CICD runs when code gets push to remote git. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353309232900?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:17:02 UTC - Carlos Santana: Need to find some time on setting up same dev environment with Rust to see what problems I hit https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353422234000?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:20:00 UTC - Roberto Diaz: Currently using the native action approach is really easy to develop and test because basically you have binary executable for each function that you can run in your terminal before create the action. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353600234200?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:21:24 UTC - Roberto Diaz: the only problem with the current approach is the needed to recompile your code into the container arch, which is really easy to solve with a simple sh script :stuck_out_tongue: https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353684234400?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:25:31 UTC - Roberto Diaz: I think that the idea behind the runtime is that the process should be easier than the current one. One thing is true, this new implementation using the `<http://lib.rs|lib.rs>`, if you want to test the function locally you need to create your own `<http://main.rs|main.rs>` locally, import your lib and call it which could be more tedious from a developer point of view... https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552353931234700?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:32:24 UTC - Carlos Santana: that's what I do for Swift a main.swift that I use to function from handler.swift, for Go I just have unit tests that I use my functions https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354344234900?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:37:14 UTC - Roberto Diaz: I don't know if I'm going to say a crazy thing :sweat_smile:. What about just upload the code in a zip, compile it on the fly generate the binary and storage the binary to be executed as a native action? https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354634235100?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:37:54 UTC - Carlos Santana: hu? https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354674235300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:39:08 UTC - Carlos Santana: For rust it should follow same options as go and swift, upload single source file, upload zip with source code, and upload zip with compiled/exe https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354748235500?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:40:57 UTC - Carlos Santana: Docker Action you get for free, in case you need to extend runtime FROM openwhisk/action-rust, add your things, create new rust image, then use new runtime with any of the 3 options source file or zip `wsk action update myaction <http://myrust.rs|myrust.rs> --docker user/mynewrustruntime:latest` https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354857235700?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:43:03 UTC - Roberto Diaz: ok! I didn't know that! https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552354983235900?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:44:41 UTC - Carlos Santana: is the same for all other runtimes, I can extend the nodejs runtime/image, create my own with pre install package.json any binary libraries and then just `wsk action update myaction mynodejs.js --docker user/mycompanystandardnodejs:1.1` https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552355081236100?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 01:45:02 UTC - Roberto Diaz: cool! +1 : Carlos Santana https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552355102236300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 02:55:31 UTC - Rodric Rabbah: You might like this <https://zeit.co/blog/introducing-now-rust> https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552359331236800?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 07:38:01 UTC - Michele Sciabarra: For your information: the rust runtime ALREADY supports (thanks to actionloop) 1. upload of a single file 2. upload of a zip file (with Cargo.toml) 3. precompilation of an action in a binary format with no compilation when deploying I do better to add some notes to it :slightly_smiling_face: 100 : Roberto Diaz, Carlos Santana https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552376281237300?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 07:50:53 UTC - Roberto Diaz: After talk with @Carlos Santana why not continue with the current approach. At the end we are doing the same that have done for Swift and Go so we are creating the same workflow used for other languages :man-shrugging: https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552377053238000?thread_ts=1551890864.115200&cid=C3TPCAQG1 ---- 2019-03-12 16:40:03 UTC - Sam Hjelmfelt: Does anyone have container-creation scale and performance numbers (e.g. throughput and latency) for OpenWhisk on Mesos or Kubernetes? I am getting good results from my latest work with YARN and it would be helpful to have some kind of baseline for FaaS workloads. Looks like docker is adding ~2 seconds in my environment. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552408803238800 ---- 2019-03-12 17:33:00 UTC - Dave Grove: @Sam Hjelmfelt I did a little micro-benchmarking for my talk at KubeCon Europe 2018. Slides are here <https://static.sched.com/hosted_files/kccnceu18/dc/KubeconEurope%20-%20OW%20on%20Kube%20-%20May%202018.pdf>. Some numbers on slide 20. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552411980240100 ---- 2019-03-12 17:34:31 UTC - Dave Grove: Nothing very deep; mainly (a) cold start times are higher using KubernetesContainerFactory than using DockerContainerFactory and (b) slow log extraction on KCF impacted overall system throughput even though it was “off the hot path” https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552412071241600 ----
