kpavel / openwhisk-light Goto Github PK

repo + individual files

Seems that 'GET' is missing. Need to decide whether to implement or proxy (can start with either of the two).

$ wsk -v --apihost http://xxx:3000 property get --apibuild
whisk API host http://xxx:3000
REQUEST:
[GET] http://xxx:3000/api/v1
RESPONSE:Got response with code 404
Resp Headers
{
"Connection": [
"keep-alive"
],
"Content-Length": [
"145"
],
"Content-Security-Policy": [
"default-src 'self'"
],
"Content-Type": [
"text/html; charset=utf-8"
],
"Date": [
"Sun, 21 May 2017 13:53:12 GMT"
],
"X-Content-Type-Options": [
"nosniff"
],
"X-Powered-By": [
"Express"
]
}
Response body size is 145 bytes
Response body received:

Cannot GET /api/v1

whisk API build Unknown
error: Unable to obtain API build information: The connection failed, or timed out. (HTTP status code 404)

Simplify the deployment when deployed in a container on the same docker engine as the action containers, e.g.:

• make the 'docker host' parameter optional (use socket interface or find docker URL automatically)
• don't require surfacing docker remote API (by using socket interface)
• find network, ports automatically

• keep activation details in a local Pouch (?) DB
• use same schema (if possible) as the one in Bluemix, to make it easy to add replication later on
• implement 'get', 'result' CLI
• implement 'list' without pagination/limits (return all)

Also, need to document (in readme) behavior of all the commands (e.g., in a table specifying "local", "delegate to cloud", "not supported")

E.g., to invoke other actions
Seems that the only thing missing is proper env variables in the action containers

add option to config (file or ENV?) whether to retry or to burst
(eventually - should work for both blocking and non-blocking, but can start with one which is easier to implement)

• update according to actual impl
• if there are important design enahncements that haven't been implemented yet -- add issues

See DESIGN.md for details

See DESIGN.md for details

avoid code duplication in actions._getAction and actions.getAction

Will be eventually removed by preemption logic

when logs returned by "wsk activation logs" the result is correct, while when activation returned by wsk activation get the result contains obsolete " characters

Make it possible to run basic operations without connection to centralized OpenWhisk

• 'action create'
• 'action invoke'
• 'action delete'
• activations
  (other?)

At the moment activations are persisted in pouchdb, on disk (using leveldb).
It would be useful to enable the following modes (at configuration time, config.js + ENV):

1. pouchdb with leveldb backend (current)
2. pouchdb with memory-only backend (https://github.com/pouchdb/pouchdb/tree/master/packages/node_modules/pouchdb-adapter-memory)
3. no pouchdb at all
   We should also check the memory footprint of each option (e.g., docker stats) - in particular, to verify whether option 3 is much more memory efficient.

actionproxy.run(actionContainer, api_key, params)
backend.getActionContainer(actionName, actionKind, actionImage)
backend.fetch()
backend.createContainer(actionName, actionImage)
actiovations.buildResponse [remove]
actions.buildResponse [remove]

e.g., 'wsk action invoke /whisk.system/utils/echo -r -p aaa bbb'
looks like a problem with routing logic in routes/index.js

logging, formatting, const vs var, file headers (license etc), function headers (comments)

Keep in mind that the catalog can be updated from a different endpoint, so we need the basic mechanism to update the local 'cache'. We can then add hooks to trigger the update by certain events (periodically, by 'invalidation' logic, etc).

See DESIGN.md for details

after action been updated, all running containers with all instance action should be deprecated (removed from pool)

Make it possible to contribute to the community a version without preemption

add headers to 'public' functions

See DESIGN.md for details

when action update/create invoked via openwhisk light need to support seamless update actions in cache

For blackbox actions, we need to pull the image from docker hub as specified in the action metadata. This is not going to work if the hardware architecture of the Docker host is different than the one that the particular image was built for (e.g., ARM vs x86_64).
Given that Docker doesn't seem to have a proper support for this (yet?), we can use tags or suffixes to enable maintaining different versions of the image for difference kinds of architecture (e.g., "myappimage-x86_64" vs "myappimage-arm"), and dynamically pull the one matching the target architecture (e.g., based on uname -i).

Encapsulate action-related properties and methods into a class