Hi Scott, – What's this for? I'd appreciate a detailed explanation of what "Enhance > CQLSSTableWriter to notify clients on sstable production" does and how it's > meant to be used. Why is it needed for rolling upgrades? The phrasing of > the ticket right now reads as nice-to-have rather than must-have. An > earlier email described the value as "code quality and brings other > benefits," but I'd expect the standard for feature backports to be higher. >
The patch to the "CQLSSTableWriter" is to support sending notification to clients (Cassandra Analytics) when a new sstable is produced. Cassandra Analytics, on receiving the notifications, can send sstables more eagerly, hence reclaiming local disk space sooner. To clarify, the patch is *not* needed for rolling upgrade. I mentioned in an earlier email that if not backporting, there will be a different solution for the lower version. The value of backporting is to eliminate the need to develop and maintain multiple solutions (in Cassandra Analytics). – What's not possible if this isn't backported? What experience suffers > today for lack of it / what problem does it solve? And what is the > alternative/fallback if others are not supportive of backport? > It has *no* impact on the Cassandra server. W/o backporting, it affects the Cassandra Analytics only. The problem and the alternative are stated above. And to the last question, the answer is that it is *not* required for upgrade. Thank you for putting the questions together. Others probably have the same questions. Hopefully it clears your concerns. I also agree that 4.1.x release should not be blocked by this patch. - Yifan On Wed, Jul 31, 2024 at 2:14 PM C. Scott Andreas <sc...@paradoxica.net> wrote: > There are a few things unclear to me in this thread and the ticket, and > details in the Jira are slim. > > Yifan / others supportive of backporting this feature, could you help me > answer these questions? > > – What's this for? I'd appreciate a detailed explanation of what "Enhance > CQLSSTableWriter to notify clients on sstable production" does and how it's > meant to be used. Why is it needed for rolling upgrades? The phrasing of > the ticket right now reads as nice-to-have rather than must-have. An > earlier email described the value as "code quality and brings other > benefits," but I'd expect the standard for feature backports to be higher. > > – What's not possible if this isn't backported? What experience suffers > today for lack of it / what problem does it solve? And what is the > alternative/fallback if others are not supportive of backport? > > – If this is deemed required for upgrade, that means users of previous > releases would have to first upgrade to the latest release on their current > train before upgrading to the latest major version. This is not a pattern > that has been required in the past, and we should not introduce such a > requirement. Do you intend this to be the required path for 4.1.x upgrades > to 5.x+? > > My general thoughts: > > – The patch is small and the feature is small so I don't have much concern > with a backport; zero-ish vote. > – It definitely shouldn't block release of the current 4.1.x vote thread > that's in progress. > – We shouldn't introduce upgrade paths that require users to upgrade to > at-minimum-patchlevel versions of current releases before upgrading to > future majors; I'm -1 on that. > > Thanks, > > – Scott > > On Jul 31, 2024, at 2:04 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > > I'm kind of neutral on this, maybe -0. It's a small enough patch, but > it's of limited value, given that Cassandra Analytics doesn't work with > vnodes. That's the overwhelming majority of deployments. So I'm not really > sure what we gain here. > > On Wed, Jul 31, 2024 at 1:58 PM Yifan Cai <yc25c...@gmail.com> wrote: > >> Hi PMC team, >> >> There are so far two +1 and one -1. Please vote if you want to. It is >> open for another 12 hours. >> >> 4.1 is to be released. I would like to include the patch, if possible, >> according to the vote result. >> >> I recognize that patches to stable releases can be risky. When talking >> about the trade off, we need to evaluate the benefit holistically, >> considering all the projects under the Cassandra umbrella. >> We surely do not want to backport the user-facing Cassandra features and >> potentially demotivating upgrade. >> IMO, the internal changes should be treated differently, as long as the >> public interface does not change. In this particular case, Cassandra >> Analytics provides the same bulk write feature regardless of backporting >> the patch or not. But having the patch backported improves the code quality >> and brings other benefits. Hope it answers Mick's message. >> >> Maybe it is time we start to think about categorizing the interfaces in >> Cassandra into 1) public API, 2) internal API, and 3) evolving API, etc. It >> is not a suitable topic for this thread and requires a separate discussion. >> >> - Yifan >> >> On Tue, Jul 30, 2024 at 11:47 AM Mick Semb Wever <m...@apache.org> wrote: >> >>> reply below. >>> >>> We're moving into a world where we will likely more frequently modify >>>> the mainline branch with new functionality to integrate with ecosystem >>>> changes (sidecar, analytics, drivers?). It's probably at least worth a >>>> conversation as to whether our current policy (improvements and new >>>> features main branch only) is optimal across everything equally or if there >>>> should be nuance for ecosystem integrations. >>>> >>> >>> >>> This also incentivises intentionally not introducing support for that >>> api in older mainlines. We KISS, if the user wants that ecosystem benefit >>> they need to upgrade to at least mainline X. >>> >>> Once older mainlines have it then we have this problem. An alternative >>> to the risk of having to always update all the mainlines, is to let the >>> ecosystem branch to provide support for the different mainlines as/when >>> needed. Both are painful. >>> >> > > > >
