> For me there's clearly no requirement to have that feature in 1.0. Why would there be?
So I am not sure whether this classifies as a "requirement' but the primary problem is that a certain set of users cannot move from Akka to Pekko because they are using Akka in a cluster and it's not an option for them to completely shut down the cluster. In my view it would be disingenuous to completely outright dismiss this concern, however of course we can manage when it's done (that's the point of this discussion thread). Specifically regarding why it was aimed for 1.0.x, the reasoning behind this was that 1.0.x branch was meant to be a "transitory" branch, that is for 1.0.x * Behaviour sticks to Akka 2.6 as much as possible (i.e. no additional features, even bug fixes unless critical/security) * Contains additional code for helping users migrate from existing Akka clusters to Pekko ones The primary motivation is that 1.1.x becomes our main working branch (i.e. main) and it would be a "clean" branch, and by "clean" I mean that the 1.1.x branch doesn't contain any cruft regarding migration. This is also about sending a clear signal to the community, i.e. as a user once you move from Pekko 1.0.x to Pekko 1.1x then all Akka compatibility concerns are thrown out of the window. You can also read https://github.com/mdedetrich/akka-apache-project/discussions/28 for the original reasoning/discussion on this point. > To focus on our current state, there's no one who currently cares that all the nightly cluster tests are green or that we organize machines that could run the multi-node tests. So, we are far from adding any new features in that area. Well if no one is interested in testing the mixed cluster scenarios then we have to recalibrate anyways because honestly there isn't a point in contemplating this for 1.0.x. However if someone steps up and provides a strong indication that they would be willing to help test it I don't think we shouldn't dismiss that. I believe sponsoring in the traditional way is not how Apache works since it's a community (not a company) and they don't want to be in a position of being dominated/influenced by a single company sponsoring them for specific features, so any "sponsoring" would be helping out in the general sense of contributing. On Thu, Feb 16, 2023 at 1:07 PM Johannes Rudolph <[email protected]> wrote: > For me there's clearly no requirement to have that feature in 1.0. Why > would there be? > > Whether it is feasible to add this feature in the future depends > mostly on sponsoring. If any of the many companies that asked would be > able to step up and contribute that feature or pay for its development > and testing then we might get the feature, otherwise we won't (I'd be > glad to work on this if someone would sponsor it but my estimate would > be at least a month of work, since this is an enterprise feature that > will need support in deploying, testing it etc). > > To focus on our current state, there's no one who currently cares that > all the nightly cluster tests are green or that we organize machines > that could run the multi-node tests. So, we are far from adding any > new features in that area. > > Johannes > > On Thu, Feb 16, 2023 at 11:50 AM Matthew Benedict de Detrich > <[email protected]> wrote: > > > > Historically (even before Pekko was accepted into Apache Incubator) > discussions have been made about implementing changes to Pekko so that it > can run alongside Akka in existing Akka clusters which is necessary to > migrate from Akka to Pekko (in a rolling release fashion) without having to > shut down the cluster. > > > > Initially it was planned to have such functionality in the 1.0.x release > of Pekko since a non trivial amount of people asked for it. On the one > hand, having such functionality in Pekko 1.0.x would send a very strong > impression which could theoretically increase the amount of > adoption/visibility however there are concerns about whether this is > feasible without pushing the release out even further. > > > > My initial impressions is that the actual amount of technical work > required to achieve this is not a lot (in fact arguably its even lower than > anticipated, i.e. see > https://github.com/apache/incubator-pekko/issues/108#issuecomment-1400078644) > but I predict largest bulk of work is not in the implementation of the > necessary changes, but rather all of the mix cluster testing that needs to > be done in order to verify that everything works correctly and we didn't > miss anything. > > > > Personally I think that doing this for 1.0.x is achievable without > pushing the release out significantly but only if people within the Pekko > community are willing to test mix cluster setups (on the assumption that as > mentioned before, the actual technical changes required aren't that > extensive). As I see it, the most active committers right now are working > at capacity on the large bucket list of changes that needs to be done to > get Pekko release out (on top of that there are other competing concerns, > i.e. trying to get snapshots for other Pekko modules so that at least the > community can test/try it out) and at least for me I don't have the time > (or even in house knowledge) on mix cluster testing. > > > > Thoughts? > > > > -- > > > > Matthew de Detrich > > > > Aiven Deutschland GmbH > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > m: +491603708037 > > > > w: aiven.io e: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
