Opened https://github.com/apache/incubator-openwhisk/issues/3944 to track the proposal as per #C above
Chetan Mehrotra On Thu, Aug 2, 2018 at 2:43 PM Chetan Mehrotra <[email protected]> wrote: > 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 >
