openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sven Lange-Last" <>
Subject RE: Dangers of renaming and removing runtime kinds
Date Tue, 17 Sep 2019 06:42:43 GMT
Hello Dave,

I absolutely agree that all adopters running Apache Openwhisk as a private 
or public production offering will or even should have their own runtimes 
manifest - like we do in IBM.

At the same time, we are using the Apache Openwhisk test suite to run 
against our IBM version of the system. When action kinds change in this 
test suite ("java" to "java:8"), this requires some work on our side. I 
admit that's our problem.

With my proposal to improve documentation, I wanted to make adopters aware 
of what runtime changes mean. Even if adopters have their own version of 
the runtimes manifest, I guess they start with a copy of the Apache 
Openwhisk default manifest. So when they set up their runtime manifest, 
they hopefully keep the new description to make maintainers of the file 
aware that removal of runtime kinds needs to be planned carefully.

Mit freundlichen Grüßen / Regards,

Sven Lange-Last
Senior Software Engineer
IBM Cloud Functions
Apache OpenWhisk

Find me on:  

Schoenaicher Str. 220
Boeblingen, 71032

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, 
HRB 243294

From:   "David P Grove" <>
Date:   2019/09/17 00:31
Subject:        [EXTERNAL] Re:  Dangers of renaming and removing runtime 

"Sven Lange-Last" <> wrote on 09/16/2019 
> I opened PR #4627 to improve documentation. Said PR also adds
> "documentation" to the pre-defined Openwhisk runtime manifest files to
> make developers aware that renaming or removing runtime kinds can cause
> problems.

Hi Sven,

                 This is useful to write down.  It should be an item in a 
practice guideline for operators of OpenWhisk deployments.

                 I think the community assumption is that all downstream 
operators are maintaining their own internal versions of runtimes.json
precisely because they need absolute control over their set of supported
runtimes.  And because they don't actually use the default runtimes.json,
they should be insulated and able to consume all schema-preserving 
changes related to runtimes.json at their own pace.

                 It is a good point that the community could have made it 
more obvious
to downstream operators that there was a change they needed to consume
carefully in PR#4390 by leaving behind a deprecated kind for some period 


View raw message