For 1. The cli now is doing the inference for you, sure we can replace that inference with an image name so instead of --kind python you'd write --image openwhisk/python. But...
The issue more generally however is if you don't solve 2, making it easier for users to use images is going to get them penalized for using arbitrary but openwhisk-compatible images. So without addressing how to pull images to local docker registries at create time for example, this is a non starter in my opinion. The difference with the openwhisk/* images is that they are already pulled, hence that addresses 2 for a limited set of images. These are the popular images, per se. If we're missing one, we add it to the manifest. There is still, I posit, a need to know which are the "popular" or approved images to use. That's what the manifest now centralizes into the deployment configuration. -r > On Mar 10, 2017, at 2:01 AM, Alex Glikson <[email protected]> wrote: > > I can think of couple of ways to make what you called "kind-aware > blackbox" actions more developer-friendly: > 1. Support them in the CLI (i.e., supporting both "image" and "code" > arguments). This would make the developer experience straightforard. > 2. Generalize the caching/pooling mechanism to handle *popular* images, > rather than a hard-coded set of "native" kind images. This would eliminate > the performance overhead. > > Regards, > Alex > > P.S. Once we do #1 and #2 above, my claim is that we don't need > pre-defined set of "kind" images any more, and just need a flexible > hierarchy of images that anyone can reuse and extend > > Markus Thömmes <[email protected]> wrote on 10/03/2017 12:48:17 AM: > >> From: Markus Thömmes <[email protected]> >> To: [email protected] >> Date: 10/03/2017 12:48 AM >> Subject: Re: factoring out "runtimes" into deployment configuration >> >> What you're referring to is basically a "kind-aware" blackbox >> action, where you get the easyness of injecting your code and the >> flexibility of using whatever you want in the image as long as the >> interface fits. >> >> I generally like the idea and brought it up as well once (i custom >> built a blackbox to do something similar). Note though that the same >> performance implications as with blackbox images apply. >> >> Von meinem iPhone gesendet >> >>> Am 09.03.2017 um 23:43 schrieb Dascalita Dragos <[email protected]>: >>> >>> With the "runtimeManifest" property I'm wondering if we can also > expose the >>> name of the container image instead of having to compute it in the > code ? >>> Extending the thought: what if we allow users to specify a custom > container >>> name when creating / updating actions, in case users want to ? >>> >>> I'm thinking at the use-case when a package with a group of actions >>> requires multiple libraries for each action. To simplify my example > I'm >>> going to refer only to JS actions: >>> - Today: when actions needs extra libs users have 2 options : >>> a) create a zip >>> b) browserify/"compile" JS into a single JS file >>> - What I'm thinking: allow users to create their own "runtime" image >>> where they can bundle those dependent libs into. All the actions in > the >>> package would be smaller, they would use less space and would probably > flow >>> easier through the system when being invoked. A potential problem in > this >>> case would be whether it's secure to let users push their own images > in the >>> OW nodes, but at the same time allowing them to upload a ZIP is >>> conceptually also a "package"/"container" that can contain anything; I >>> guess the security aspect would still remain even with user-defined >>> containers. >>> >>> Dragos >>> >>> >>> >>>> On Tue, Mar 7, 2017 at 4:20 AM Michael Marth <[email protected]> > wrote: >>>> >>>> Hi Rodric, >>>> >>>> I think that?s great. >>>> >>>> Only comment (more to Matt than you): >>>> If the runtimes are dynamic by deployment (and of course over time) > this >>>> probably should be reflected in the packaging format spec [1]. >>>> (see also previous comment [2]:) >>>> >>>> - line 252: not sure if the list of runtime names should be in the >>>> normative >>>> section of a spec, because (as you also write) this list will > fluctuate >>>> between >>>> deployments and over time. OTOH there should be established well > known >>>> names for >>>> well-known runtimes. Maybe point to a community-curated, separate > markdown >>>> file >>>> (where new entries get a PR that can be voted upon)? >>>> >>>> Cheers >>>> Michael >>>> >>>> [1] >>>> https://github.com/openwhisk/openwhisk-wskdeploy/blob/master/ >> specification/openwhisk_v0.8.pdf >>>> [2] http://markmail.org/message/pa35wxxl52tvbfxc >>>> >>>> >>>> >>>> On 05/03/17 17:39, "Rodric Rabbah" <[email protected]<mailto: >>>> [email protected]>> wrote: >>>> >>>> I've been thinking about how we can add more action runtimes more > easily - >>>> without changing the backend (API, controller, invoker, CLI). One way > I'm >>>> leaning toward and started prototyping to get a better understanding > of the >>>> feasibility is to strip all runtime types from the backend (and CLI) > and >>>> encode the information about what action runtimes the system supports >>>> through configuration parameters. >>>> >>>> This will make it possible to decouple deploying the core components > from >>>> managing the action runtime images. An example of encoding the > runtime >>>> information in a deployment configuration is >>>> https://github.com/openwhisk/openwhisk/pull/1948. >>>> >>>> In support of this general direction (even if we settle on a > different >>>> approach), I have increasingly flattened the "Exec" type hierarchy in > the >>>> backend[1-3] >>>> >>>> [1] https://github.com/openwhisk/openwhisk/pull/1938 >>>> [2] https://github.com/openwhisk/openwhisk/pull/1942 >>>> [3] https://github.com/openwhisk/openwhisk/pull/1911 >>>> >>>> A sketch of how to use the runtime manifest can be seen in this WIP > commit: >>>> >>>> https://github.com/rabbah/openwhisk/commit/ >> a8890abe51a3e7e6a34f96a46798de660583e36f >>>> >>>> I can see how using this we can add new versions of Node.js, > python:3, and >>>> other handy images by curating a list of these in a separate process. >>>> >>>> Feedback, as always, solicited and appreciated. >>>> >>>> -r >>>> >>>> >> > >
