openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <>
Subject Re: Updating Package and Language versions for a kind
Date Fri, 14 Jul 2017 17:08:31 GMT
Hi Michael, all,

I wonder how many deployments roll their own action containers? I suspect not many.

I agree with you both that it would be nice to keep packages (modules) up to date on a regular
basis within a kind makes the most sense and a regular schedule would be nice, especially
if there's a documented way to do the update for each kind. 

I think we should also keep the language of the kind up to date at the *patch* level on the
same cadence too. e.g. Node 6.11.0 to Node 6.11.1 - unless there are language kinds that break
semver at the patch level? (In which case my head may explode!)

For minor releases, it's a little more wooly at the moment at least. For NodeJS, [PR 2078
 [1] simply updates the `node6` kind from 6.9.1 to 6.11.0  without creating a new new "kind".
However, for Swift, [PR] [2120] gave us a new `swift:3.1.1` kind rather than updating the
`swift3` kind which runs Swift 3.0. I'm not sure that Swift 3.1.2 will need its own kind though,
so maybe it should have been called `swift:3.1`? 

My thoughts on this is that we should create new kinds for minor language releases on the
principle of least surprise for the container users.

I would like to fairly aggressively deprecate old ones to stop new actions being created for
out-of-date language versions, but as deprecating a kind prevents invoking any actions for
that kind that's not possible unless some work is done to allow invoking actions on a deprecated
kind, but not creating or updating them would be necessary for that to be a possibility. 

I think GitHub Issue [319] [3] is relevant in terms of the tooling around this.




> On 14 Jul 2017, at 16:27, Michael Marth <> wrote:
> Rob, all,
> I largely echo what James wrote below (except moving this discussion off-list :) )
> Incidentally, we had a very similar discussion within my team recently on how to handle
this topic for our OW deployment. The bottom line is that the trade-off between stability
and being up-to-date can only be decided in a given business context of the OW deployment.
> We (as a project) do not have that context and cannot really make the decision, IMHO.
In that light the only reasonable policy in my view is to strive to keep everything updated
as best as we can, like monthly or every second month, etc.
> If we miss a beat (i.e. don’t immediately update to latest release) I don’t think
that’d be critical. Like James said, most OW providers will have their own runtimes anyway
and would (should) take the latest if they need it.
> Cheers
> Michael
> On 13/07/17 11:02, "James Thomas" <> wrote:
>> Good ideas Rob. I had a similar issue when looking at the Swift runtime
>> recently.
>> Would it be possible to have a scheduled upgrade process for installed
>> modules? Once every four, six or eight weeks? If OpenWhisk did start to
>> produce "releases", it could tie in with that.
>> I'd guess that most people using the built-in packages are more kicking the
>> tires than building production apps. Once you start being a production app,
>> you'll want to explicitly bundle and control your app dependencies. I'd +1
>> on being more aggressive with upgrading module versions.
>> I'd like to have a Github issue to follow for this, I find it easier than
>> the mailing list.
>> On 13 July 2017 at 09:33, Rob Allen <> wrote:
>>> Hi all,
>>> On the PHP PR, @rr [commented] [1]:
>>>> The built in packages are convenient - less zip files for the initial
>>> ramp up. But it creates a maintenance issue: when do you pick up updates to
>>> the packages (minor/patch level only?) and not break existing actions using
>>> the "kind". That is: is the kind itself semantically versioned?
>>> This applies to all kinds and so probably should be discussed project
>>> level and ideally we should document how this is handled.
>>> There are two things here:
>>> 1. The language runtimes release patch updates for minor versions. e.g.
>>> PHP `7.1.7` will become `7.1.8` next month with a small number of bug fixes
>>> including crashers and possibly security fixes.
>>> 2. Each kind bindles a number of packages via the language's standard
>>> package management system: Swift Package Manager for Swift, NPM for NodeJs,
>>> etc. The projects that produce these packages update them with new versions
>>> minor and patch versions.
>>> The tension is obviously between keeping updated for fixes vs the risk of
>>> breaks due to a project's inability to keep BC between patch versions. e.g.
>>> the NodeJS kind comes with the `async v2.1.4` package. However `v2.1.5` of
>>> that package fixes a stack overflow issue. Should our actions have that
>>> fix? Closer to home, the NodeJS kind ships with `OpenWhisk v3.3.2`, but the
>>> latest is `v3.6.0` which is needed for non-experimental API Gateway support…
>>> Some questions:
>>> 1. Should we update the language runtime for a kind for a patch level
>>> change (e.g. update the current NodeJS:6 kind from `6.9.1` to the latest
>>> `6.9.5`?
>>> 2. Should we ever update the language runtime for a kind for a minor level
>>> change (e.g. update the current NodeJS:6 kind from `6.9.1` to the latest
>>> `6.11.1`?
>>> 3. Should we ever update the packages in a kind to the latest patch level
>>> or minor level?
>>> 4. What's our policy when a security issue is published for a language or
>>> a package that we ship in a non-deprecated kind?
>>> Whatever the answers are, I think we should document them clearly
>>> somewhere.
>>> Also, I've started this conversation as a mailing list topic as it's a
>>> "policy" thing. Given my previous comments on mailing lists, should I also
>>> create a GitHub issue prefixed with "Discussion" to provide more visibility
>>> in order to garner wider community input?
>>> Regards,
>>> Rob...
>>> [1]:
>>> issuecomment-314716101 <
>>> incubator-openwhisk/pull/2415#issuecomment-314716101>
>> -- 
>> Regards,
>> James Thomas

Development thoughts at
Daily Jotter for macOS at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message