apache / openwhisk-runtime-docker Goto Github PK

Fix by #3

Current master build is failing with following error

fatal: [controller0]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: {u'replicationFactor': u\"{{ kafka_replicationFactor | default((groups['kafkas']|length)|int) }}\", u'version': u'0.11.0.1', u'port': 9092, u'heap': u\"{{ kafka_heap | default('1g') }}\", u'ras': {u'port': 8093}}: 'dict object' has no attribute 'kafkas'\n\nThe error appears to have been in '/home/travis/build/apache/openwhisk/ansible/roles/controller/tasks/deploy.yml': line 77, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: (re)start controller\n  ^ here\n"}

Tried to use latest version of gevent 1.3.6
It looks like starting with version 1.3 we can't longer import the way is currently from gevent.wsgi import WSGIServer we need to use from gevent.pywsgi import WSGIServer

I propose we update the python code to hande the latest gevent version, and at the same time also update flask to latest.

Not being specific here causes python3 to try an ipv6 address first which fails on kernels/OS which do not contain the ipv6 module.

Fixed by #2

The Java proxy does not permit an action to be re-initialized [1]. This isn't true for the docker proxy or Python/Swift runtimes. All the runtimes should behave consistently. The basic action container tests suite will be extended to include a test for re-init, where the first init is expected to succeed but the second should fail. The action proxy will reject the request with status code 403 FORBIDDEN (although any non-20x is acceptable for rejection).

[1] https://github.com/apache/incubator-openwhisk-runtime-java/blob/3657b3889fd1ce03581184fcb07766a8c897a4d8/java8/proxy/src/main/java/openwhisk/java/action/Proxy.java#L72-L75

Making the fix at this level will address python and swift proxies as well.

Update the Travis build to push a tag "master" to Docker when the master branch is updated.
This will make it easier to pull the image that aligns with the latest changes on the Master branch.

Reference can be taken from: apache/openwhisk-runtime-java#37

TLDR; have the python proxy set current directory to /action/

The current directory is set to default meaning currently is /actionProxy/
When using a zip action the contents of the action is extracted to /action/
If the zip file has more files and the exec binary needs to reads the file the location would be /action/file.txt for example.
I think is better to have the current directory set to /action/ this way the exec can assume the relative directory to exec or zip is the current directory hiding any implementation details of /action and also making testing the action locally easier before build the zip and deploying.

This is already handle in python zip action correctly via os.chdir

from the IPMC release vote

at least this file https://github.com/apache/incubator-openwhisk-runtime-docker/blob/master/sdk/docker/buildAndPush.sh has the wrong (short) license header.

useful to have zip utility, allows to compress a payload, or use it for devops to deploy zip actions.

Would be useful to have git utility in dockerskeleton
Allows users to build devops actions where they can git clone and build/compile/package some code and deploy

allow shell/bash actions to handle better action inputs

cc @rabbah

Currently we have own copy of actionproxy.py for swift4,

I would prefer to have actionproxy.py in a central location and then pull via Dockerfile

The change is to allow a parameter zipdest like I'm doing right now in swift4

https://github.com/apache/incubator-openwhisk-runtime-swift/blob/master/core/actionProxy/actionproxy.py#L50-L54

More info in cross reference issues:
apache/openwhisk-runtime-swift#15

adding perl allows for perl actions.
wsk action create action action.pl --native
or
CLI can be updated to handle .pl extensions

wsk action create action action.pl

This will pick up updated alpine linux.

Following Apache license header guideline, all human-readable Apache-developed files that are included within a distribution must include the header text with few exceptions. You can find few exceptions here: which files do not require a license header.

I used Apache Rat to check this repository after excluding a few files, and I got this report. We need to add Apache licensing header to those files.

Unapproved licenses:

  openwhisk-runtime-docker/core/actionProxy/Dockerfile
  openwhisk-runtime-docker/tests/dat/blackbox/badaction/Dockerfile
  openwhisk-runtime-docker/tests/dat/blackbox/badaction/README.md
  openwhisk-runtime-docker/tests/dat/blackbox/badproxy/Dockerfile
  openwhisk-runtime-docker/tests/dat/blackbox/badproxy/README.md
  openwhisk-runtime-docker/tests/src/test/resources/application.conf
  openwhisk-runtime-docker/ansible/environments/local/group_vars/all
  openwhisk-runtime-docker/ansible/environments/local/hosts
  openwhisk-runtime-docker/sdk/docker/Dockerfile
  openwhisk-runtime-docker/sdk/docker/example.c

The excluded files are:

**/*.json
**/**.gradle
**/gradlew
**/gradle/**
**/.**
**/templates/**
**/*.j2.*
**/.github/**
**/auth.whisk.system
**/auth.guest
**/i18n_resources.go

user reported that using a bash script in dockerskeleton they can't git clone a url using ssh scheme

git clone [email protected]:apache/incubator-openwhisk-runtime-docker.git

I'm guessing is because the image is missing the ssh client or some ssh client side config.

We should not enable/install ssh server/deamon/service, but look if it's possible to just add the minimum to make the git clone work over ssh.

This is a test issue to see if the email notifications are going to issues@ and not dev@ for the Apache OpenWhisk mailing lists.

Hi,

Following along http://jamesthom.as/blog/2017/01/16/openwhisk-docker-actions/ (section Running Locally), I've been able to quickly iterate on a custom action/runtime, but for a specific issue: /action/exec ends up not being executable as a result of initCodeFromZip.

The local file is 0755, but once pushed within the container as part of a base64 zip, it's 0544 (or 0744 I don't remember 🙈) and belongs to the root user. Therefore POST /init kept failing on this line, specifically the os.X_OK check (which was not obvious at first but the local dev setup turned out great to debug as well).

To work around the issue, I edited both initCode* functions to add os.chmod(self.source, 0755) right before their return statements (could be refactored to DRY things up):

     # initialize code from inlined string
     def initCodeFromString(self, message):
         with codecs.open(self.source, 'w', 'utf-8') as fp:
             fp.write(message['code'])
+            os.chmod(self.source, 0755)
         return True

     # initialize code from base64 encoded archive
     def initCodeFromZip(self, message):
         try:
             bytes = base64.b64decode(message['code'])
             bytes = io.BytesIO(bytes)
             archive = zipfile.ZipFile(bytes)
             archive.extractall(self.zipdest)
             archive.close()
+            os.chmod(self.source, 0755)
             return True
         except Exception as e:
             print('err', str(e))
             return False

I'd like to believe it's a safe move to make, but I'm not sure really. What do you maintainers think? If it sounds about right, I could create a quick-win PR for this of course.

Dev setup: fresh Debian Stretch install, Docker version 18.06.1-ce, using openwhisk/dockerskeleton:latest as build image. Dev source code available here (specifically the Dockerfile).