openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <mich...@sciabarra.com>
Subject Re: Interpretation of "main" for GoLang and ActionLoop docker images
Date Sun, 07 Oct 2018 11:49:12 GMT
At the moment it works looking for a file named after the main function.It is not a big deal
to change to a fixed name and it would als
simplify the logic: if there is an exec file, try to execute it
otherwise try to compile.I will try to implement this logic.
--
  Michele Sciabarra
  michele@sciabarra.com



----- Original message -----
From: Carlos Santana <csantana23@gmail.com>
To: dev@openwhisk.apache.org
Subject: Re: Interpretation of "main" for GoLang and ActionLoop docker imagesDate: Sat, 6
Oct 2018 14:32:45 -0400

Another thing to discuss is the name of the executable inside the zip
file
TLDR; Use "exec" as the entry point binary executable inside the zip

I think we should keep some consistency with how we handle it today in
dockerskeleton where we us by convention "exec"
This exec is the entry point, no manifest file is to point to it is by
convention in the root of the zip. this allows to have a zip with a bashscript and other files,
for someone to migrate fo actionloop
makes it lesschanges.
This exec can be a bash script, a perl script, a rust binary, a go
binaryas long it conforms with the contract today to take the "value"
json objectin stdin and exit with the last line to print is json out.

With the new golang and actionloop we should do the same
The exec in the root of the zip is the entry point binary (go, rust) orscript (bash, perl,
etc), the contract would be different.
The contract is take the whole /run json including value and the other
envvariables in stdin, exec doesn't exit, the output goes to fd3 not
stdout,and it loops again to grab next invocation fro stdin, with a new set of"value" and
environment variables (i.e deadline, etc..)

If "exec" can only be use for actionloop, and for a good reason not in
golang runtime I'm ok just want to understand and discuss pro and cons

-- Carlos



On Mon, Oct 1, 2018 at 9:33 AM Carlos Santana <csantana23@gmail.com> wrote:
> I agree Michele to leave it simple interface with the constraint that> Function has
to be in main package.
>
> We can capture the feature as a future thing in the issue
> tracker to see> if we get feedback and someone wants to contribute that piece, it
> will not> change the API to the compile command it will still backwards
> compatible.> Were today is "compile <Name of Function in main package>" and
in the> future like you said it can be "compile <package>.<Name of Function in>
package>"
>
> For the thing about using a file with no extension call main, I
> agree this> was one of the feedback I gave you that that we should allow
> the user to> define the function in any file with extension .go as long the
> user exposes> the function in the expected way main.Functioname (already
> capitalize, we> don't mock or touch user code, the user needs to use Capitalize so
the> launcher can be able to reach it)
>
> I think we should ask the user to have the source code in the
> correct way> with the function name already Capitalize, and the compiler should
> not have> to replace any of the user code.
> Yes they can use "compile Funcname" or "compile funcname", but when
> process it will be process as Funcname with first letter Capital.
>
> -- Carlos
>
>
>
> On Mon, Oct 1, 2018 at 6:51 AM Michele Sciabarra
> <michele@sciabarra.com>> wrote:
>
>> About  -main "foo.Bar" there are 2 problems doing that.
>>
>> First thing, I need to "capitalize" the main function name.  So
>> "--main>> main"  means "Main" in package "main"
>>
>> Why? Because In Go there is only one main in package main with
>> signature>> "()" and I need to use it for the "startup" code.
>>
>> So I have use either another name or "main" another package. But
>> if I use>> for example "main" in another package... I have the problem that
>> whatever>> function I use it must be capitalized anyway because that is the
>> Go way to>> say "public".  Initially it was "action.Main" the I decided that
just>> leaving in "main" package was fine no need to specify an arbitrary
>> package.>> Also because usually files in "main" package are left in the
>> root while>> other packages are in subdirectories.
>>
>> So the simplest solution it to interpret "main" as "main.Main" and
>> "hello" and "main.Hello".
>>
>> Is it possible to use "-main package.function" ? Well it is but...
>>
>> 1. I would need to split "package" and "function" then capitalize to>> "Function"
and interpret as "package.Function" (because for sure
>> Package.function is NOT going to work..."
>> 2. in the startup code I do not have only to replace the function
>>    name>> but also add "import "package"" somewhere.
>>
>> Not sure it is worth the effort because it is pretty ease to write a>> function
in main package that will forward to whatever entry point
>> in inner>> packages we may want.
>>
>>
>> If you have better ideas they are welcome.
>>
>> --
>>   Michele Sciabarra
>>   michele@sciabarra.com
>>
>> ----- Original message -----
>> From: Rob Allen <rob@akrabat.com>
>> To: dev@openwhisk.apache.org
>> Subject: Re: Interpretation of "main" for GoLang and
>> ActionLoop docker>> images
>> Date: Sun, 30 Sep 2018 21:38:49 +0100
>>
>> Hi Michele,
>>
>> From a someone who doesn't use Go, this all seems sensible and
>> predictable to me, though I have one question that may show my
>> lack of>> knowledge of the language!
>>
>> > Case4: sending a zip with source actions. Here is where the current>>
rules turned out to be very confusing. So I am going to simplify
>> this way:>> >
>> > You can upload all the files you want in your zip file, they
>> > must all>> have .go extension and they will be compiled. You must NOT
have a
>> main.main>> function as this will be provided by the runtime. The name of
>> the main>> function will be interpreted as in 3: -main main (or default) =>
>> main.Main>> , -main hello => main.Hello
>>
>>
>> Does this mean that I can't specify a different module other
>> than main>> for entry point? e.g. would  -main foo.Bar work and result in the
Bar>> function in the foo package being the entry point to the action?
>>
>> This is on my mind as I'm considering updating the PHP (and Python?)>> runtimes
to support setting the file as well as the function name
>> and would>> use the format -name foo.php:bar to run the bar() function in
>> foo.php as>> the entry point. (Currently, the filename is hardcoded to index.php).>>
>> Regards
>>
>> Rob
>>
>>
>>
>>
>> > On 29 Sep 2018, at 09:03, Michele Sciabarra <michele@sciabarra.com>>>
wrote:
>> >
>> > Hello all,
>> >
>> > I need to discuss my plan for simplifying rules for interpreting
>> > "main">> for Golang.
>> >
>> > The rules I have used for interpreting the "main" parameter in wsk>> turned
out to be a bit confusing, so I plan to make them simpler.
>> This is>> what I plan to implement, please confirm it is fine OR tell me if
>> there is>> something I should change. The text below will go in documentation
>> if it is>> ok.
>> >
>> > ----
>> [snip]
>>
>> --
>> Development thoughts at http://akrabat.com
>> Daily Jotter for macOS at http://dailyjotter.com
>>
>>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>


Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message