Re: Travis problem with runtime-docker
Of course I just noticed when the `./gradlew install` is fast, is because the openwhisk/tools/travis/setup.sh script does ./gradlew :tests:compileTestScala, which is indeed much slower. I also noticed the gradle versions are different between main repo and runtime-docker, so will try out updating runtime-docker to same gradle version... On 10/1/18, 4:45 PM, "Tyson Norris" wrote: Hi – I’m troubleshooting a problem with this PR build [1] where a test fails due to a difference in exception handling between akka http client (now used in runtime test base class), and apache http client. This change was merged to OW master some time ago in [2]. The problem I’m having is that the builds and test work great locally. The travis build is behaving as if the tests base classes (built by cloning incubator-openwhisk, and running `./gradlew install`) are not installed fresh each build, but I cannot see anywhere in travis config or build scripts where they might be cached. One reason I suspect cacheing (aside from the build failing) is that the elapsed time spent in `./gradlew install` is 15s in travis – this is way faster than I ever see running the same on a clean system locally. Any ideas? Thanks Tyson [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fapache%2Fincubator-openwhisk-runtime-docker%2Fbuilds%2F435891993&data=02%7C01%7Ctnorris%40adobe.com%7Cdc85e3274e6e46f2524408d627f7eeb2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636740343143609349&sdata=4%2FOZEvMg04O%2BfmGRvvv9QOM0qS4Np6uQDTO%2Fnxi7LSg%3D&reserved=0 [2] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fcommit%2F15bb04a449f621d262c2687a7b8417241f3856b8&data=02%7C01%7Ctnorris%40adobe.com%7Cdc85e3274e6e46f2524408d627f7eeb2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636740343143609349&sdata=dzr76uuIp0DYLF4e%2FpqYvMxUKg5L2lFNTFqzBBlDKyA%3D&reserved=0
Travis problem with runtime-docker
Hi – I’m troubleshooting a problem with this PR build [1] where a test fails due to a difference in exception handling between akka http client (now used in runtime test base class), and apache http client. This change was merged to OW master some time ago in [2]. The problem I’m having is that the builds and test work great locally. The travis build is behaving as if the tests base classes (built by cloning incubator-openwhisk, and running `./gradlew install`) are not installed fresh each build, but I cannot see anywhere in travis config or build scripts where they might be cached. One reason I suspect cacheing (aside from the build failing) is that the elapsed time spent in `./gradlew install` is 15s in travis – this is way faster than I ever see running the same on a clean system locally. Any ideas? Thanks Tyson [1] https://travis-ci.org/apache/incubator-openwhisk-runtime-docker/builds/435891993 [2] https://github.com/apache/incubator-openwhisk/commit/15bb04a449f621d262c2687a7b8417241f3856b8
Instruction documented to release openwhisk projects under apache
Hi openwhiskers, I have documented the instruction to release openwhisk module under Apache as release manager at https://cwiki.apache.org/confluence/display/OPENWHISK/How+to+release+OpenWhisk+under+Apache+as+incubator+project For folks, who are interested in driving the release effort of openwhisk in future. This is the guideline you can refer to. You can give it a skim. Feedback is welcome. Thanks. 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: Donation of ibm-functions/composer to Apache OpenWhisk
Bertrand Delacretaz wrote on 10/01/2018 08:02:34 AM: > > Please also create a ticket for the IP clearance then, listing the > names of the code authors and ideally including a link + digest to a > zip or tar archive of the code that's being donated. Or just attach > that archive to the ticket if it's small enough. > > We can create the Git repositories ourselves via > INVALID URI REMOVED > u=https-3A__gitbox.apache.org_&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=Fe4FicGBU_20P2yihxV- > apaNSFb6BSj6AlkptSF2gMk&m=SAMRTIrnjjEawPAy9yNV_Spq4QS9mh4XcOMe3MhcAQk&s=8XoUNXZwMPaPD59W0TU9mTg5UKa1QjVqXXom6cFiu_A&e= > so if infra works is needed it's best to > wait until that repository is up before creating infra tickets. > > -Bertrand Thanks for the guidance. I just created the github repo. Olivier is doing some cleanup of the documentation to remove references to IBM Cloud Functions. Once that is done, I will submit the IP clearance form. --dave
Re: Interpretation of "main" for GoLang and ActionLoop docker images
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 " and in the future like you said it can be "compile ." 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 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 > mich...@sciabarra.com > > - Original message - > From: Rob Allen > 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 > 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
Re: Donation of ibm-functions/composer to Apache OpenWhisk
Hi, On Mon, Oct 1, 2018 at 6:40 AM Bertrand Delacretaz wrote: > On Sat, Sep 29, 2018 at 12:20 PM Rodric Rabbah wrote: > > ...There are five contributors. > > Of those, the four contributors from IBM already have Apache CLAs on file: > > Olivier Tardieu, > > Nick Mitchell, Kerry Chang and Rodric Rabbah > > I agree that if all authors have Apache iCLAs on file, a Software Grant is > not needed... That is correct but rereading http://incubator.apache.org/ip-clearance/ and especially the IP clearance template at [1], the IP clearance form must still be filled and accepted by the Incubator PMC as described there. But if all authors have an iCLA on file there's no additional paperwork needed. On Fri, Sep 28, 2018 at 4:56 PM David P Grove wrote: > ...Unless there are objections raised here on the dev list, I will plan to > submit the infra tickets on Monday... Please also create a ticket for the IP clearance then, listing the names of the code authors and ideally including a link + digest to a zip or tar archive of the code that's being donated. Or just attach that archive to the ticket if it's small enough. We can create the Git repositories ourselves via https://gitbox.apache.org/ so if infra works is needed it's best to wait until that repository is up before creating infra tickets. -Bertrand [1] http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/ip-clearance-template.xml
Re: Interpretation of "main" for GoLang and ActionLoop docker images
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 mich...@sciabarra.com - Original message - From: Rob Allen 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 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
Re: Interpretation of "main" for GoLang and ActionLoop docker images
Yes the issues are there. But it is still confusing the current way it handles the main in a source zip. It requires you have a file named "main" (lower case) without .go extension, ( while other files are WITH extension) and a main function that is called Main (capitalized). Too complex. I want to remove at all the "main" file requirement (not necessary) and use the name of the function to point the main function, whenever it is. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Carlos Santana To: dev@openwhisk.apache.org Subject: Re: Interpretation of "main" for GoLang and ActionLoop docker images Date: Sun, 30 Sep 2018 16:22:23 -0400 Michele, I have being using the runtime this week and looks very good. Based on my findings and as discuss in Slack I think all the changes are captured as issues in the repo, if any are missing please open issues to coordinate. In addition of having the compiler out of the box which I think is great, I think we need a docs on how to setup a local dev, like having a VSCode and have tests file that can run the function without having a main.main defined this was an area I was confuse since I usually have a main function to run my go code. — Carlos On Sat, Sep 29, 2018 at 4:03 AM Michele Sciabarra 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. > > > > There are 4 cases to send input to the runtime: > > 1. Sending a precompiled binary, specifying a main function > 2. Sending a zip file including a binary > 3. Sending a single source file > 4. Sending a zip file with multiple sources. > > Case 1: Sending a precompiled binary, specifying the main function > In this case, the main function will be ignored. > > Case 2: sending zip file including a precompiled binary > In this case, the main function will be the name of the file in the zip > > Case 3: sending a source action > > In this case, the main function will point to the CAPITALIZED function in > package main. > I need this capitalization because in Go I cannot use main.main because it > is reserved and I use it for the bootstrap code. > > Example: -main "main" => Main function is "main.Main", > -main hello, main function will be "main.Hello". > Also if I use -main Hello it will be "main.Hello". > > 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 > > Compiler: > > The go runtime provides also a compiler to "precompile" the actions. > Using the compiler you can run the actions with just the generic > "actionloop" container, smaller since there is no go compiler in it > > The compiler must be fed either a source file as in Case 3 or a zip file > conforming the Case 4 and will always produce a ZIP file containing a > binary according to case 2. > > So it will be somewhat like this: > > To compile: > > zip - -r * | docker -i openwhisk/actionloop-golang-v1.11 -compile main > >main.zip > > this will compile the sources expecting a main.Main function and will > produce a zip file with a main. > > This can be deployed with: > > wsk update action golang-action main.zip -docker opewhisk/actionloop > > Example using a different name: > > If you want to use "hello" you can use: > > zip - -r * | docker -i openwhisk/actionloop-golang-v1.11 -compile hello > >hello.zip > > This will look for a function main.Hello in the sources, and will produce > a zip file with a hello file. > > This will have to be deployed as: > > wsk update action golang-action hello.zip -main hello -docker > opewhisk/actionloop > > --- > > Thoughts? > > > > > > -- > Michele Sciabarra > mich...@sciabarra.com > -- Carlos Santana
