Okay the PR is ready for review everyone! Just one failing unit test I'm working on and a flaky one. I've updated the description of the PR noting all of the changes made. I went through the entire diff myself as well and think it looks good. I also added a notice to the top of the base readme of notice of the breaking change.
@Dominic It is a single commit, just one PR. Though there are a few deprecations to deal with on the latest Pekko that fail compilation from warnings. I've decided to isolate this to a small second PR fixing deprecated references that re-enables failing compile on warnings. I've gone through them, they're essentially just renames. On Fri, Oct 17, 2025 at 7:58 AM David Grove <[email protected]> wrote: > +1 from me too. Thank you for taking this on. > > From: Rob Allen <[email protected]> > Date: Friday, October 17, 2025 at 5:05 AM > To: [email protected] <[email protected]> > Subject: [EXTERNAL] Re: Apache Pekko Migration > > Hi, > > This sounds like an excellent thing to do. I’m not qualified to review at > all, but I’m in full support of the move. > > Regards, > > Rob > > > On 16 Oct 2025, at 20:16, Brendan Doyle <[email protected]> > wrote: > > > > Hello whiskers, > > > > It's been a while! I'm reaching out today about migrating Openwhisk off > of > > Akka to Apache Pekko. Following the license change of Akka back in 2022, > > the Apache community created a fork to maintain the open source nature of > > the Akak framework within the Apache organization. Three years later, the > > project is quite successful and stable such that I feel we are ready to > > make the cutover. As far as I know, all other Apache projects that were > > taking dependency on Akka have already made the switch. > > > > Why do this now or at all? > > > > 1. We have been stuck on Akka 2.6 for over 3 years. The core framework of > > the project dictates what other versions of transitive dependencies we > can > > run. Without being on a version of Akka / Pekko that is actively > > maintained, we cannot properly patch dependencies to handle critical bug > > and security fixes. > > 2. Many of the dependencies we rely on are severely outdated due to the > > reliance on the last Apache licensed version of Akka. Taking this > > opportunity to cutover to Pekko allows us to do major revisions on > > dependencies that are long overdue. > > 3. By having the project in this healthy state again, it should motivate > > people to make small updates as needed surrounding tooling and running > the > > project that would be an insurmountable change in the current state. > > > > I have a PR <https://github.com/apache/openwhisk/pull/5551 > open that > is > > near ready for review, which is why I'm sending out this email now to get > > attention as soon as possible. I just have three failing unit tests > > remaining to resolve. I have already tested the change in running > clusters > > and all looks good. The PR may look daunting at +400 files, but I promise > > after doing a self review this morning only about ~25 files require any > > look, mainly the dependency and configuration files. I estimate it will > > take approximately twenty minutes of your time to review. The rest of the > > files are just import name changes. The PR is clean and only updating > > dependencies as necessary. The cutover to new clusters should be quite > > transparent apart from the changes under the hood from where we were on > > Akka to the latest version of Pekko, which in my wide experience with > Akka > > should be trivial from where we were on 2.6. > > > > *Here is the important part. Merging this in will be a breaking change so > > far as it requires you to start new Openwhisk clusters through blue / > green > > deployment. Rolling upgrade of existing clusters will not work. While > > Apache Pekko supports rolling restart cutovers, our current state does > not > > leverage this because we are on Akka GRPC 1.x and Akka Kryo serialization > > w/ Kryo4. Pekko is forked off of Akka GRPC 2.x and Akka Kryo > serialization > > w/ Kryo5. Both of these major upgrades would require new clusters even if > > remaining on Akka. Now is a good time to get them out of the way so we do > > not have to address this again indefinitely since we'll be on the latest > > Pekko GRPC major and *Kryo5* serialization is latest.* > > > > Now on how do we integrate this into the project. Either we merge my PR > > directly to master or we open a v3 branch. With the current velocity of > the > > project such that for a couple years now the only updates have been > > dependency and build updates, my opinion is we just go straight to master > > especially with the bug and security fixes included. Additionally, we > only > > ever had one official release of 2.x which was also a breaking change in > > similar capacity. Besides getting eyes on the PR, I'd appreciate > responses > > on if people are okay with merging the PR directly to master and changing > > the version to a 3.0.0-SNAPSHOT? > > > > Lastly, I would like to take this opportunity to discuss with the > community > > our status and our use of the project for full transparency. We have been > > working for a couple of years on our next generation platform and > strategy > > for internal usage of FaaS and will be winding down our usage of the > > project by 2027. When it is all said and done, this project will have > > served us well for nearly a decade. I would like to take a moment to > > applaud @style95 and his whole team for what they accomplished with the > > scheduler. Without this work, we would not have had the stability to > > allocate resources to work on the platform that would come next for us > for > > the last two years. > > > > For me, I will still be around personally to give feedback on any project > > discussion or help keep things healthy with build and dependency updates > > after 2026. Following this change, it should be trivial for us to keep > the > > Apache project stable for a very long time for the open source and > research > > community to continue on or expand Openwhisk. > > > > Thanks, > > Brendan Doyle > > > > Brendan Doyle > > Staff Software Engineer, Async Platform > > > > > > > > > > Brendan Doyle Staff Software Engineer, Async Platform 410.829.9908
