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
E-mail: [email protected]
Find me on:
Schoenaicher Str. 220
Boeblingen, 71032
Germany
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" <[email protected]>
To: [email protected]
Date: 2019/09/17 00:31
Subject: [EXTERNAL] Re: Dangers of renaming and removing runtime
kinds
"Sven Lange-Last" <[email protected]> wrote on 09/16/2019
01:51:11
PM:
>
> 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
best
practice guideline for operators of OpenWhisk deployments.
I think the community assumption is that all downstream
OpenWhisk
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
upstream
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
of
time.
--dave
