Action Code Handling
====================
If you know how action code is handled then skip this section
Currently in OpenWhisk the code related to action is stored in one of the
following form
1. Inline code as string
"exec": {
"kind": "nodejs:6",
"code": "function main(params) {var name = params.name ||
\"World\"; return { payload: params }; }\n",
"binary": false
}
Code here may be
- Literal string
- Base64 encoded string
2. Stored as attachment
{ "exec": {
"kind": "java",
"code": {
"attachmentName": "couch:73d6c4cc-3670-4328-96c4-cc3670a328ac",
"attachmentType": "application/java-archive"
"length": 32768,
"digest":
"sha256-5a373715b8cdcd608059debe9dae2ad95087eb5322321d1d0b862f8330a0e54d"
},
"binary": true,
"main": "hello"
}
}
Here the code stored as attachment is the raw content. When it is read in
memory then it is stored as Base64 encoded string
How it gets stored is currently determined by the manifest [1]. If the
manifest entry for specific runtime has `attached` attribute specified then
the related contents would be stored as attachment otherwise the content is
stored as a string property `code`. Per defaults
- java - Stored as attachment
- blackbox - Stored inline
- other kinds - Stored inline
Problem
=======
In our case where actions are stored in CosmosDB it enforces a limit of 2MB
on document size. So storing large code for action like nodejs does not work
Solution Options
=============
A - Change manifest in our setups
---------------------------------
In our setups we can change the runtime manifest and use attachment for all
kinds.
Cons
- Requires migration of existing content
- Blackbox still pose a problem
B - Change default manifest
---------------------------
Bit similar to #A but also done for Blackbox action and implemented in
backward compatible way.
C - Rely on inlining within ArtifactStore
-----------------------------------------
With #3709 inlining support was added to ArtifactStore. With this
ArtifactStore would try to store an attachment as inlined Base64 encoded
string if the size is less than certain threshold (16 KB per default). This
ensures that using attachment mode does not incur cost of an extra remote
call for small codes
This would need change in current logic to drop use of manifest for
deciding the storage for all code types (blackbox, others)
Pros
- Let ArtifactStore decide which code to inline irrespective of type
Cons
- Some code may end up as attachment and thus incur an extra call to fetch
them while executing an action
- System admin cannot control the storage mode based on type
Questions
========
There is already a PR #3286 which implements #B approach (except the
Blackbox part). So wanted to check
1. Which approach to take
2. Is PR #3286 complete or some aspects are pending
3. Should we extend #B (and thus PR #3286) to implement approach #C i.e.
drop manifest support and support Blackbox
4. Should we do this incrementally i.e. get #3286 merged -> support
blackbox -> drop manifest attachment config
regards
Chetan
[1]
https://github.com/apache/incubator-openwhisk/blob/master/ansible/files/runtimes.json
Chetan Mehrotra
