Re: Upcoming changes in the Go runtime for... future expansion

[Carlos Santana]

+1

Not just but I think a lot kind of languages will benefit c++, rust, we can
even use it to migrate with little effort bash and perl all them relying on
the foundation of new lean and mean go proxy :-)

—Carlos
On Fri, Mar 9, 2018 at 2:03 PM Michele Sciabarra 
wrote:

> I am loyal to the classical apache way, where everything was happening on
> the ML, so even if the discussion was sorted out in Slack, I drop an email
> here to let everyone else to know what is happening.
>
> Basically, there is a "secret plan" to conquer the world... well to make
> Swift actions (that are pretty important) faster.
> And also another one to implement streaming, but this is another story.
> So I will have to make the go runtime compatible to allow for those
> expansions.
>
> In short, while by default Go logs in stderr, Swift by default logs in
> stdout... and it will mess out the "conversation" with the pipe. To avoid
> this problem, I will have to write the answer on another channel, leaving
> stdout AND stderr for log... because Go logs by default on stderr, and
> Swift logs by default in stdout ...
>
> Another problem is the handshake. Well it is not really a problem except
> ... the current implementation of init is lazy and does not do many checks.
> They rely on the timeout to get rid of misbehaving actions.
>
> In conclusion I am going to change the Go runtime this way:
>
> - accept more or less any  stuff the user sends
> - detect more errors at /run-time
> - write output in (ouch!) channel 3 (argh!) to prepare to support Swift
> - rely in timeout (that force a kill of the runtime) for cleaning the mess
> (a.k.a.: if I spill on the floor I will wait for the cleaning woman)
>
> Guys, did I miss something?
>
> --
>   Michele Sciabarra
>   openwh...@sciabarra.com
>

Re: [LONG] Discussing my implementation of Go actions

[Michele Sciabarra]

> I would prefer it not be there, but can see the convenience of detecting 
> that an app has immediately crashed. If we can find another way to do 
> that via process inspection, that would be better in my view.
> 
The problem can be summarised into this code:

// this command exits
cmd := exec.Command("true")
out, err := cmd.StdoutPipe()

err = cmd.Start()
fmt.Println(err)
   // this is nil! no error!

// even worse! attempted to detect
err = cmd.Process.Signal(syscall.Signal(0))
// this is nil too! no error!
fmt.Println(err)

So, how can I check the process is actually terminated ? 

Re: Error when deploying Whisk-Controller in dcos

[Duy Nguyen]

Hi Kumar,

> 1) What should be the APIGATEWAY_DNS value? It is needed to install the
next packages.
> 2) You mentioned “make sure Route53 record was set up correctly” in
README . What should be done to verify it? Can you please give me step by
step instructions on how to verify it?

I think both questions come down to the point that you need a DNS to expose
the gateway.
There are various options for this. Our team uses Route53, basically by
mapping our DC/OS public slave address to a wildcard DNS (e.g. *.
openwhisk.example.com, which is set for APIGATEWAY_DNS in the deploy script).
I think the approach is the same even if you are using a different DNS
service.
If all go well, you should be able to access to your marathon services by
their service names, like controller.openwhisk.example.com.
We are aware that the api gateway flow is not perfect atm, and still
working on improving it. If you have any idea for this, please let us know.
:)

> Also some of the environment variables are missing like
DB_WHISK_ACTIVATIONS,KAFKA_HOSTS,CONTROLLER_INSTANCES,
CONTROLLER_LOCALBOOKKEEPING,AKKA_CLUSTER_SEED_NODES etc….

Those are defined in the mustache configs, which are exposed via DC/OS
configs.
https://github.com/apache/incubator-openwhisk-deploy-mesos/pull/2/files#diff-168a01e8dada294dd2d623a1aee704ed

cheers,
Duy


On Wed, Mar 7, 2018 at 10:06 PM, Kumar Subramanian 
wrote:

> Just consolidating the questions <>
>
> On 3/7/18, 11:56 AM, "Kumar Subramanian"  wrote:
>
> Hi Duy,
> I was able to install the api gateway by calling make api-gateway.
> But, it was not straight forward. The api-gateway was in the waiting state
> for a long time. I had to suspend the deployment; set the acceptedRoles to
> null and restart the deployment then it worked (please see my earlier mails
> regarding probem with Api gateway installation)
>
> Question:
> 1) What should be the APIGATEWAY_DNS value? It is needed to install the
> next packages.
> 2) You mentioned “make sure Route53 record was set up correctly” in README
> . What should be done to verify it? Can you please give me step by step
> instructions on how to verify it?
>
> Thanks,
> Kumar.
>
> On 3/7/18, 11:15 AM, "Kumar Subramanian" 
> wrote:
>
> Hi Duy,
> One your instructions at https://github.com/duynguyen/
> incubator-openwhisk-deploy-mesos/tree/dcos-universe/dcos-deploy-script
>
> You mention “make sure Route53 record was set up correctly” . What
> should be done to verify it? Can you please give me step by step
> instructions on how to verify it?
>
> Thanks,
> Kumar.
>
> On 3/7/18, 10:52 AM, "Kumar Subramanian" 
> wrote:
>
> Hi Duy,
> I got your PR on my local MAC. I have a dcos cluster on remote
> machines. What are the instructions to deploy openwhisk to this dcos
> cluster?
>
> Thanks,
> Kumar.
>
> On 3/7/18, 1:38 AM, "Duy Nguyen" 
> wrote:
>
> Kumar - The PR has not been merged yet. Could you pull the
> PR itself to try?
> https://urldefense.proofpoint.
> com/v2/url?u=https-3A__github.com_apache_incubator-
> 2Dopenwhisk-2Ddeploy-2Dmesos_pull_2=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=
> F5C8fYlpBJ270qrdwLq2iRQrPd1CLap8zItxk8laWpo=afQz0NoScGRmefphc9MyV-bV9-
> 5iIC7nrIHVkvZv8gM=8q_6zaOcuwSuhZ4IcwVYfBZL2SAx6Jf9NGoyYbitGp0=
>
> cheers,
> Duy
>
> On Tue, Mar 6, 2018 at 7:45 PM, Kumar Subramanian <
> kumarsubr...@vmware.com>
> wrote:
>
> > Hi Duy,
> > I would love to try it.
> >
> > Is your changes in master? If so what’s master link?
> >
> > In the link https://urldefense.proofpoint.
> com/v2/url?u=https-3A__github.com_apache_incubator-
> 2Dopenwhisk-2Ddeploy-2Dmesos=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=
> F5C8fYlpBJ270qrdwLq2iRQrPd1CLap8zItxk8laWpo=afQz0NoScGRmefphc9MyV-bV9-
> 5iIC7nrIHVkvZv8gM=V6KK9cxXZORCCW_qK6d4qxaZC5vg-CajM4UQnusaP4c= I
> > only see a license.txt file in it.
> >
> > Thanks,
> > Kumar.
> >
> > On 3/6/18, 9:41 AM, "Duy Nguyen" 
> wrote:
> >
> > Hi Kumar,
> >
> > I have updated the universe to latest Openwhisk
> changes, verified it
> > on a
> > vanilla DC/OS 1.11 cluster, and opened a PR at [1],
> do you mind trying
> > it
> > out?
> > Hope it would solve bunch of issues you got earlier.
> >
> > cheers,
> > Duy
> >
> > [1] https://urldefense.proofpoint.
> 

Re: [LONG] Discussing my implementation of Go actions

[Carlos Santana]

Thank you Michele for the contribution.
I already provided some initial feedback in the PR

https://github.com/apache/incubator-openwhisk-runtime-go/pull/1


On Fri, Mar 9, 2018 at 6:13 AM Michele Sciabarra 
wrote:

> I just did a  PR of my version of the Golang action implementation. It
> does some "breaking" changes  and there is some discussion on the slack
> channel.
>
> So I report the current situation n here, looking for advices and change
> recommendations.  Since I am a bit confused, if I remember well, one Apache
> rule is  the mailing list is the ultimate source for the truth...
>
> It currently works this way (I call it the "pipe-loop" protocol)
>
> A golang action (or a generic binary) is expected to follow this
> "protocol":
>
> * starts with  {"openwhisk": 1}
> * reads on line in stardard input, expecting a json ON A SINGLE LINE
> * process the line, emits logs in stderr (can be multiple lines)
> * outputs a line in stdout in json format ON A SINGLE LINE
> * repeat forever
>
> It is important to note this design is easy to implement and works even
> for bash scripts, but it is easy to use also perl, ruby, haskell in an
> EFFICIENT way.  Indeed this bash script (with jq) is part of my tests:
>
> ---
> #!/bin/bash
> echo '{"openwhisk":1}'
> while read line
> do
>name="$(echo $line | jq -r .name)"
>logger -s "name=$name"
>hello="Hello, $name"
>logger -s "sent response"
>echo '{"hello":"'$hello'"}'
> done
> ---
>
> Things discussed:
>
> 1) ​remove the header {"openwhisk":1}
>
> Actually initially it was not there. But I decided to add this
> requirements because the action need to speak a protocol ANYWAY.
>
> Most important, I explain why I require it starts with "{"openwhisk: 1}".
>
> The main reason is: I start the child process at init time, and I wanted
> to detect when it does not behave properly.
>
> The simplest problem happens when the action crashes immediately. For
> example, a common reason for this problem is uploading a binary using some
> dynamic libraries not available in the runtime. For  example a swift
> action. By defaults it load a lot of different libraries, it crashes
> immediately but I cannot detect it until I try to read its stdin.
>
> I can remove this requirement if someone can show me the go code to check
> that cmd.Start("true") or cmd.Start("pwd") exited 
>
> If it is not doable, and I skip  the handshake, even if the command
> crashed, I will not detect the problem until a /run is executed and the
> action times out...
>
> Carlos say it is fine. It is ok for me but I still think an early problem
> detection would be better. Also James recommended me to provide as much as
> error detection to the user as early as possible. Kinda of conflicting
> directives here...
>
> Suggestions?
>
> 2) more checks at init time
>
> I added some sanity checks.  Probably too many. I tried to detect the
> error at deployment time, not at invocation time.
>
> This is different from what currently for example dockerskeleton does.
>
> If I upload for example something wrong, like a non-zip, a non-elf
> executable, my init returns {"error": "description"}, while currently the
> dockerskeleton returns always OK.
>
> Recommendations here?
>
> 3) output to another channel the result
>
> Currently I require logs goes to stderr, and stdout is for interacting
> with the parent process.
>
> Rodric suggested to output to a separate channel (channel 3?)  and use
> stdout and stderr for logs.
>
> While doable, I need to provision another pipe, and the implementation
> should probably do some syscalls to retrieve file descriptor 3. It would
> complicate implementation, while currently it is straightforward for any
> language that does not have a library available. For swift, even to flush
> stdout I needed to write "linux specific" code... I do not dare to think
> what I need to do to write in fd3...
>
> My opinion is that using stdout for I/O and stderr for logs is a better
> choice than opening another file descriptor.
>
> Thoughts here?
>
>
>
>
>
>
>
> --
>   Michele Sciabarra
>   openwh...@sciabarra.com
>