Hello all, Following our meeting last month, I want to start the discussion on doing a new major release of Openwhisk and what we need to have done before doing so. These are exciting times as this work has taken us years to get us to this point. Work on the new architecture began before Covid and now here we are in 2023 nearing the finish line. Thank you to all that have made contributions to the project over the last few years.
The plan is to make Openwhisk 2.0.0 default to the new scheduling architecture. We will keep the old invoker / controller scheduling code in the repo for now for existing users that rely on the old architecture and are not comfortable upgrading. I believe that the new scheduler is production ready or at least as close as it's going to get before an initial release and we can continue to sniff out any remaining bugs. These are things I would like to see get done before we cut a major release: 1. Max Instance Concurrency for Action Configured by User <https://github.com/apache/openwhisk/pull/5287> 2. Built In Action Versioning <https://github.com/apache/openwhisk/pull/4986/> 3. Cutting over to Pekko if we decide that's the path forward from Akka. This discussion is still sort of pending. The release becomes dependent on an initial Pekko release if we decide to go with Pekko. If there's any special migration procedure for an existing cluster, this is why I'd like to see this included in the major version release so we don't have to do another. 4. Documentation for upgrading to 2.0.0 w/ the scheduler service and any behavior changes from 1.0.0 / the latest commit on old architecture. 5. Nice to have would be a public article from the PMC team on the new architecture and benefits of 2.0.0. 6. Zookeeper removal would be nice to have but I don't think it should be a blocker since it's such a minor dependency w/ alternatives already as I removed the requirement to supply the config, I believe it can be removed later with a minor release. Now, I would like to open the floor if there's any low hanging fruit that we would like to take the opportunity to remove by having a new major release. I.e. are there any deprecated runtimes default bundled in with the release that we would like to remove entirely from the repo, changing any defaults, etc? This is not meant to be the vote on a new release, just discussion as we start preparations. Part of this discussion can be what kind of timeline we think is reasonable. Thanks, Brendan Doyle
