I think the PR is a good start, but I also think upgrading OpenWhisk is a
hazardous area that has broader scope that operators need to consider when
running OpenWhisk with any custom configuration (and nobody should probably run
with default config, but I guess technically it would be possible).
Considerations include:
* which custom invoker/controller akka configs may conflict with new config
defaults?
* runtime manifest changes or runtime changes (if you use public runtimes)
* kafka message schema changes
* docker image command/args changes that may surface if you have a custom
deployment to run public images
* db changes (I guess less likely an issue since most operators would not run
"custom schemas" on the db?)
I'm not sure how to produce an exhaustive list, but it may be something we
should add to an "upgrading openwhisk" section of an "operators guide" - I
don't know if such a guide currently exists.
Thanks
Tyson
On 9/16/19, 11:43 PM, "Sven Lange-Last" <sven.lange-l...@de.ibm.com> wrote:
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
